What's been happening?

September 1st, 2008

Posted at 10:47pm by Stan

I've been playing around with Google Gears on an application I work on in my spare time. That application is heavily driven by jQuery, and the decision to leverage Gears came with mixed emotions. In the developer's FAQ there's a pretty diagram which recommends utilizing a "data switch" between the user interaction and the subsequent process. I think this is Google's clever way of saying, make your application driver-driven! This makes sense and fits the design too...

Let's get hypothetical and say we have an interface for your hypothetical driver has two methods, one for reading and one for writing. In driver implementation A AJAX requests are fired off for reading and writing your data, however in driver implementation B we'll rely on locale storage - in this case, Gears. With jQuery you normally just write the act of reading or writing into the handlers, however that just doesn't cut it once you have alternative sources that those handlers need to deal with. One option is to simply test for which "driver" you need and use conditionals to get where you need to going. I like to look ahead though, and surmise that some day I may want to add support for Safari's HTML5 Database Implementation in addition to my online mode and my Gears support. Who knows too... if the application ever gets ported over to Adobe AIR we've added a fourth data source to the mix.

The point is we need to abstract this stuff out. One option is to simply test if you need a driver and then overwrite the handlers, first unbinding them and binding new ones in their place. But what do you do when you want to switch back? We can start encapsulating stuff in functions for binding all of these elements, but we wind up reusing a lot of code in the process. As best I can tell, right now there is one other option, and that's to create an object and have all of the event handlers reference that option for certain tasks. This object then can be dealt with as you're switching between states, but ultimately parallels a traditional driver-based design pattern. The down side to this is it suddenly doesn't look like unobtrusive javascript code (ie. jQuery).

I'm wrestling with what my alternatives to that final solution are... right now it doesn't seem like there are any. I confess I was tempted by Low Pro for jQuery, but suspect this will be limiting in the long run. I'm wondering if anyone else has any ideas? If so, drop me an e-mail I'd love to hear about them.

Powered by BlogSCL3 0.4.0alpha