Archive for the ‘monorail’ Category

Complex UI with Monorail, Javascript & Caching

June 19, 2007

Coming to the end of the development cycle of a fairly large & Javascript dependant project, a few issues have cropped up that will probably need resolving before going full production. Im glad that hammett seems to be having similar problems, & it’s not something that has already been solved that I have ignored within MonoRail.

The first is the fact that I have alot of dependencies in javascript files, the front page of the application (& probably where the user will spend a fair amount of time) in particular depends upon Prototype, Scriptaculous, Plotkit & Mochikit and about 20 other random small javascript files, that may or may not need to be included. At the moment my BaseController exposes functions to bring in those javascript files, and code in my layout #includes the relevant nvelocity files. This is ascetically ugly as I am calling these in my controller methods (although it could be done in the views via $controller.IncludeSomeFile). Basically I Got It Working, knowing full well that it was going to be a thorn in my side, ascetically & performance wise. So I want something akin to the Helper attributes that you can decorate your controllers (and perhaps methods) with.

The current Helper system in MonoRail works fine with the scriptaculous & Prototype Helpers at the moment, but the current situation doesnt help with javascript dependencies, or caching/bundling the javascript. Ive learnt to live with manually dealing with dependencies, so that’s not a huge problem per se (I have been developing in .NET for a couple of years now :) , but I have a sneaking suspicion that the 40+ javascript files being pulled in is going to exacerbate performance problems, both on the client and server.

Starting afresh on an related project, allowed me to look afresh at the MonoRail offerings, and I of course first went to the ajax related stuff. Nice to see a BehaviourHelper, but my last project used event-selectors as I liked how it works, and hinges on Prototypes $$() support, with the peformance gains and css-selector support that engenders. I also don’t like ‘meta-programming’ as it pertains to the web, as it reminds me too much of the ol’ PHP days:

$BehaviourHelper.Register("someId", "function(el){doSomething(*);}")

my javascript function often ended up with more that just a one liner, very ugly in quoted code within a nvelocity file (no syntax!). So I first baked up a solution for EventSelectors, the patch is here. Read the patch comments for what it does, & how it builds a javascript file that contains all the relevant event selectors for that area/controller/view. I really do like convention over configuration. I hope it doesnt get lost in the castle-devel deluge…

So that’s event selectors sorted, next up I need to look at:

  • Bringing in ’standard’ javascript libraries, which may also reference css files.
  • Handling dependency trees (i.e scriptaculous upon prototype)
  • Bringing in application javascript libraries, using a convention based approach, so your javascript application code is packaged cleanly in a folder structure.
  • Handling caching of the dependency trees, and outputting concatenated/compressed javascript, just like RoR!

I’ll be putting up a class designer of my initial class design in my next post.