Architecting Laszlo Apps on the Fly

Software developers never have enough time. The code-slingers on the Laszlo Studios team are no different: we have many different projects running at any given time and strive to deliver perfect code on time scales of six weeks to three months. How do we do it? A little luck and a lot of laziness:

Create minimal structure and get going
On projects with tight deadlines, being able to find a relevant chunk of code and either fix it or extend it is more important than dealing with beautifully designed and over-engineered interfaces. Studios projects start with the creation of a few directories and main.lzx. Here's the listing from our latest completed project:

config.xml controllers/ data/ main.lzx modules/ resources/ test/ util/

Make the directories. Get main.lzx up and running. Then start coding. Dump any significant UI elements into modules/, media assets into resources/, tests into test/, and so on. Write include.lzx files in each subdirectory that include all the relevant files in that particular subdirectory. Then stop worrying about file placement. This approach scales up to medium-sized (tens of thousands of lines of code) project; developers can easily guess where particular sections of code live.

Trust yourself to refactor
Turning views into classes is a cinch in OpenLaszlo. The platform offers more than syntactic convenience, though. Dynamic typing and a prototype-based object system allow for instance-first development, something that we do a lot of here at Studios:

Crank out painfully specific code. Stick methods into instances all the time. If a piece of functionality has no place in the UI, pull it out into a controller or data manager. If you find yourself writing the same code more than twice, pull it out into a new class or write a utility function. Don't be afraid to copy and paste.

Write utilities
In the course of my last project, I kept running into the same problem: I wanted a view to grow up to a certain maximum width. I wrote a MaxWidthMixin that you can insert into any view to keep it from growing beyond a particular width:

<class name="MaxWidthMixin" extends="node">
    <attribute name="maxwidth" value="null"/>

    <method event="onwidth" reference="parent">
        <![CDATA[
        if ( this['maxwidth'] &&
             (parent.width > this.maxwidth) ) {
            parent.setWidth( this.maxwidth );
        }
        ]]>
    </method>
</class>

I include the util/ directory at the beginning of main.lzx, so all my code has access to this class. Dropping this class into a view makes for much more readable code than simply copying and pasting the maxwidth attribute and onwidth listener into many different views.

Don't be afraid to write small utilities. They'll save you some typing and make your code more legible for other developers. And be lazy about generalizing. You could conceivably rewrite MaxWidthMixin to work with any attribute of any node, for maximum values, minimum values, or arbitrary boolean functions. You'll know you need a utility when you find yourself writing the same code more than once.

Use datasets aggressively
Over the course of a project, you'll use your code in many different ways: to demo, to test, to debug, and to deploy. Datasets provide a way for your application to manage all these different situations. Use datasets from the beginning, even if they store a small amount of constant data.

Laszlo Studios projects tend to have display datasets that drive the UI and temporary datasets that grab data from a server. In my last project, I had to display a large set of words in columns. I used a temporary dataset to retrieve the list from the client's webservice and massaged the list into rows before placing it into a display dataset. My UI code is protected from changes in the webservice, and I didn't have to spend time crafting a general column layout.

Stick all the code for populating datasets into controller nodes (all collected in the controller/ directory). You may end up with a multitude of controllers of various sizes, but sticking to this rule creates a single point of reference for your application's control flow.

Conclusion
We try to keep things simple at Studios. The heuristics above are what I turn to when I feel stuck and stare at the keyboard. The OpenLaszlo team has gone to great lengths to make it easy for your code to work itself out. Following a few rules and letting go of your design a little bit will let you focus on the end-user experience of your application and deliver it on time.

Comments are closed.