Prototype.js, Ajax, and Zope

If working with the Prototype.js Javascript library is any indication of what programming Rails is like, I would say that Rails has one more interested user out there.

prototype.js says its development is driven heavily by the Rails framework, but could be used with any system since it is just a browser side Javascript library. I very rarely use Javascript. In fact, I've tended to avoid it as much as possible due to bad memories of it stemming back to the mid to late nineties. All of that changed this week. I'm still not intimately aware of how to program in Javascript, but with prototype.js I was able to put a simple AJAX based UI together in a couple of hours. Half of that time was spent learning some simple DHTML tricks, which the prototype.js library made easier. On top of its AJAX (or XMLHTTPRequest) capabilities and special effects, prototype.js adds some nice object oriented features to Javascript that made JS feel less foreign to me, and it also adds a couple of nice extra methods to the core DOM. One of those that came in handy for me was getElementsByClassName, which lives up to its name by returning an array of DOM elements with a particular CSS class name.

What I liked most about working with the prototype.js library was that while it does not come with very much at all in the way of documentation, the source code is very clean and easy to figure out. I got my user interfaces going by reading its source, using Firefox's Javascript Console, lots of page reloading, and occasional consultations to some public web applications that use this library. By the end of my first day of working with it, I realized that the style of the code was rather similar to what little Rails code I've seen.

But I don't need to concern myself with Rails or any of the scads of knock-offs based on Rails. Wiring prototype.js up to Zope required almost zero thought. Zope's been publishing objects and methods on simple URIs for longer than most systems have even existed, and throwing in a couple of Ajax specific view methods which performed their update and returned a simple string of "OK" (all that this application required) took no time at all. Note that I could very easily have dispatched off to a page template that returned HTML to display in line and Zope and prototype.js's Ajax commands would have been just as happy. So again, I tip my hat to Sam Stephenson and all who contributed for making it fairly platform agnostic when it comes to the server side. (note: the form serialization stuff could probably be tweaked / extended to work better with Zope's parameter marshalling).

So why did I decide to try Ajax / Javascript for this application? Because this is an instance where the small set of targeted users need to go through a big list and check off items as they reconcile them against another system. I decided that I would make it so that if their browser supported these technologies that the updates to the server should happen instantly so that the users don't have to go through and find the 'Update' button every time they finish the list. It's also easier now to give visual communication about cleared items since table rows in these reports can be so easily highlighted.

Combined with the browser_detect.js library, it was pretty easy to structure this UI in a series of fallbacks for browsers with less functionality, back to zero Javascript. But for the users who can do it all, it should help their job move along quicker. And I like that.