Finally this week it was my turn to ride the OpenLaszlo pony at work. My first priority was to figure out some ways in which large canvas definitions with deeply-nested views liberally soused with javascript code could be factored out into smaller and more manageable modules.

The first trick I tried was to extract any large chunks of javascript code (method bodies, etc.) into named functions in separate files, and import them with a <script> tag with a src attribute. Pretty soon I also had a couple of files with libraries of utility functions - things like setPropertyOnAll(elems, propertyName, value) which would take an array of components and make them all visible, or partially opaque, or whatever else you wanted. Javascript is an under-appreciated language, I often think - people tend to use it just for straight scripting, without realizing the power that its closures and prototype-based object system actually give you.

The next trick was to “flatten out” the source, extracting nested views and menus into class definitions in library files and then importing the libraries and dropping class instances into the places where the views had been. Again, some common patterns fairly quickly emerged - there were lots of buttons that caused a hint to appear elsewhere in the canvas on mouseover and made it disappear again on mouseout, and it was a simple matter to create a new class derived from basebutton with a hint attribute that had this behaviour baked-in.

So some of my initial worries about how OpenLaszlo code would scale were assuaged: it’s clear that you can build a full-scale OpenLaszlo application out of a collection of composable bits and pieces, provided you take care to use the appropriate mechanisms for modularity and code re-use.