Today I released jQuery Autosave a new plugin for jQuery that tracks the state of a form and fires of events to save the form data when the form has been dirtied. I use this plugin for my content management system to save changes to the user's content while they are working. I'm very interested in feedback, so please take a look and let me know what you think. The release package includes an example that demonstrates usage and how this plugin works. You can find the plugin as well as more information over at my project page.

jGrowl 1.2.4 has been release and is now available for download here. This release is primarily to fix some compatibility issues with Internet Explorer. As always, if you find any bugs or have any suggestions please contact me

I've recently release two updates to jGrowl, the most recent of which is version 1.2.3. If you are a regular jGrowl user I suggest updating to this version as it contains some important fixes when using multiple containers. Callback support has been enhanced and improved to be more robust and jQuery UI theming by way of ThemeRoller is also supported. I owe a special thanks to the community which greatly contributed to this most recent patch release - thanks!

You can find the latest version of jGrowl here.

jGrowl 1.2.1 has been released. You can find the changes here and download the release here.

I released jGrowl 1.2.0 the other day over on the jQuery plugin page. It's basically the same as the last beta, with just some minor tweaks and improvements. The big change in 1.2.0 is a queue for notifications to prevent the screen from filling up with notifications and posting them outside of the user's scope of view. More info is available here.

I've gotten a couple of e-mails asking if jGrowl was compatible with the newly released jQuery 1.3. To the best of my knowledge jGrowl is fully compatible and there are no know regressions. I would recommend using the latest 1.3.2 release of jQuery though, albeit there are no known issues the items fixed since the initial 1.3 release are worth having and could possibly effect overall behavior.

I've just release jGrowl 1.2.0beta3 over at the jQuery plugin page. This release includes some minor changes based on user feedback to the way that a notification is closed. Currently the triggers occur by the little "x" close button or by way of time elapsed or by way of the "close all" button. While it's possible to introduce your own trigger for closing a notification (for example, click anywhere on the node), it's not as easy to implement. Subsequently, the closing off a notification has been moved such that at any time you can call, jQuery("div.jGrowl").trigger("jGrowl.close); and the close operation will be initiated.

You can download this release here.

A new beta of jGrowl 1.2.0 has been uploaded on the jQuery plugin page. This latest beta fixes several syntax errors if you went to compress the library or obfuscate it, as well as fixes a major bug in the log callback. That error would have occurred in the event that a custom option object did not define a log callback. If you run into any issues or have any suggestion please feel free to send them to me. Otherwise, you can download this release here.

I've released two new versions of jGrowl this evening, the first is 1.1.2 and includes minor changes to 1.1.1. Nothing serious or exciting there. The other release is an initial beta of 1.2.0 which offers pooling capabilities. What I've noticed is that sometimes too many messages get sent to jGrowl at a given time and messages which are the bottom of a listing can expire before they ever come into view by the user. This really defeats the purpose and functionality, so I've been trying to figure out how to avoid this problem. Messages are pooled into a queue and will only be rendered in the event that the pool has now reached its pooling size. By default this functionality is turned off, however I've included an example file that enables this functionality and sets the pool size to 5 messages. For those who use jGrowl and have run into this issue I highly recommend trying out the 1.2 beta. I haven't decided if anything else is going into 1.2 yet, so you may be looking at a final release... who knows, only time will tell! :) Anyhow, feel free to provide me with feedback on this recent change. You can find these releases on the jQuery plugin page here.

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.