• It had to support checkboxes for selection, independently of normal leaf selection.
• It needed to support visual tree lines.
• It needed to support drag-and-drop both internally (i.e. from one leaf to another) and externally (i.e. to drop targets outside of the tree).
• It needed to be easy to add icons to different nodes.
• It had to support large datasets. The “official” OpenLaszlo tree doesn’t support any form of lazy replication, so it was impractical.

I started with a version of opttree that was created by Adam Wolff (formerly of the Laszlo Foundation Classes and now of ShareGrove). In the meantime, that opttree got incorporated into OpenLaszlo, although it never made it into the official component set; it’s in the incubator. (Source for that opttree). In order to meet the above requirements, I needed to refactor the code somewhat to have a more reusable base class (sharedtreenode), from which I could create the various incarnations (checktreenode, dragtreenode, etc.). Mine never made it into the official OpenLaszlo distribution, although it has been widely used after it was informally released on the OpenLaszlo forums.

Anyway, that’s the background. Here’s one incarnation (checktree) in action:

I’ve finally updated this to run on OpenLaszlo 4.7; because it wasn’t part of the official distribution, it was never kept up-to-date. You can download the source for my opttree, complete with checktree, dragtree variants, as well as examples of how to add icons, and so forth. The test cases should give you a pretty good idea of how it’s used.

PuzzlePixies.com is a children’s educational site. It’s not actually a single OpenLaszlo app, but lots of little games for different age groups.

I’ve seen some of these games before (e.g. the classic card matching memory game). But there’s something about the colors and simple graphics that seemed to appeal to my 3-year-old son immediately. Maybe it’s the fact that a child’s voice introduces each game and tells you if you got the right answer?

The whole site is free. If you have kids, check it out!

MobileDataNow uses an OpenLaszlo front-end to allow you to configure data stores and mobile notifications. From the docs, it looks like it was upgraded to some edition of OL4.

In case you missed it, the October edition is still available, which covers built-in dropshadow functionality in OpenLaszlo. Check out Raju’s blog for a demo of this feature.

• Query string parameters in a GET or a POST request.
• POST parameters.
• Raw POST data.

The first two are fairly straightforward: A query string is the part of the URL that comes after the question mark. Post parameters (as name/value pairs) can be added to a POST request by calling setQueryParam() on the dataset. If the client needs to send a large block of data to the server (e.g. an XML document) that data can be assigned to a single POST parameter.

The third one is a little more complicated. Essentially, it means all the POST body. i.e. Where the POST parameters would normally live. Older versions of the Flash Player had problems with this, so it was not possible to submit raw POST data with older versions of OpenLaszlo in SOLO mode.

This isn’t an issue today. The Flash Player can submit raw post data. So if you absolutely can’t have even a single POST parameter, you can specify content to be included in the POST body by calling:

dataset.setAttribute("querytype", "POST");
dataset.setQueryParam("lzpostbody", "CONTENT");

Note that the lzpostbody query parameter is a special name that tells OpenLaszlo to use the provided string as the entire POST body. Here’s an example of this in action:

<canvas debug="true" proxied="false">
    <dataset name="ds" src="myService.jsp" type="http" request="false"
             querytype="POST"/>

    <button>Do Request
        <handler name="onclick"><![CDATA[
            var body = '<rawpostbodycontents>Hello, this is some XML.</rawpostbodycontents>';
            ds.setQueryParam("lzpostbody", body);
            ds.doRequest();
        ]]>
        </handler>
    </button>

    <handler name="ondata" reference="ds">
        Debug.write("RESPONSE:", ds.serialize());
    </handler>
</canvas>

You can download the entire source, complete with a JSP that reads and echoes the raw POST data.

When you think about it, that’s not a silly question at all. Regardless of whether you compile an OpenLaszlo application to SWF or DHTML, you’ll have similar benefits and simliar constraints. On the positive side, coding complex and interactive user interfaces is straightforward. You’re using a language that was specificially designed for rich Internet applications (RIAs).

However, many of the problems people associate with SWF - inability to bookmark (what exactly?), lack of search engine exposure, back button integration (you want to try explaining what’s supposed to happen when you click back in a RIA), difficulty of integration with traditional HTML applications - affect DHTML-compiled OpenLaszlo applications too. Thankfully these days, most developers understand that a platform like OpenLaszlo isn’t supposed to replace HTML applications, but instead is intended for a specific type of application that’s difficult, if not impossible, to do with HTML. Think Gliffy.

So if DHTML doesn’t solve some of most long-standing “problems” of Flash, what does it offer? Certainly not media support; in fact SWF-compiled OpenLaszlo applications have more consistent support for PNG, as well as FLV, SWF, MP3.

Surely DHTML-compiled OpenLaszlo applications must offer some other benefits then? Well, they work in Webkit, which means they’ll run on the iPhone (and of course many upcoming mobile devices that use DHTML). That’s definitely an advantage, but the applications are still limited by the performance of the small CPU.

So now we get to where DHTML compilation really shines… Remember how I said that OpenLaszlo was good for some applications, and HTML was good for others? DHTML-compilation in OpenLaszlo allows you to run one or more HTML applications inside your OpenLaszlo application!

How can it do this? By using the <html> tag, you can embed another web property (e.g. a web site, HTML-based application) inside your OpenLaszlo application. Here’s an example that shows two HTML web sites embedded in the same OpenLaszlo application:

Screenshot of two HTML applications in one OpenLaszlo application

Unfortunately, I can’t simply embed this example into my blog, because it relies on the OpenLaszlo wrapper code. You have to click the screenshot above and then play with the windows.

You may be aware that SWF-compilation also supports the <html> tag. However, the problem with using the <html> tag with a SWF-compiled OpenLaszlo application is that the IFRAME which displays the HTML web site will always float above the SWF. That means you can’t really have a windowed application, unless you’re satisfied with only having one window in your entire application. And you can’t have two <html> tags, if they’re likely to ever overlap, since there’s no way to control which is on top at any one point.

As you can see, that’s not a problem for DHTML.

Download the source for this example.

The W3C provides a list of standard CSS colors, and OpenLaszlo now allows you to use those color names as strings when setting colors.

So in addition to being able to say:

myView.setAttribute("bgcolor", lz.colors.cornflowerblue);

… and of course:

myView.setAttribute("bgcolor", 0x6495ed);

… what’s new is that you can also say:

myView.setAttribute("bgcolor", "cornflowerblue");

Notice that the color name is a string, not a variable. Finally, you can also use the pound (#) notation when setting colors in script:

myView.setAttribute("bgcolor", "#6495ed");

Note that when using pound notation, the color value must be a string.

<view bgcolor="red" width="20" height="20" />
<view bgcolor="0xff0000" width="20" height="20" />
<view bgcolor="#ff0000" width="20" height="20" />

In JavaScript, you could use either the hex notation or the named color:

myview.setAttribute("bgcolor", 0xff0000);
myview.setAttribute("bgcolor", red);

Note that in JavaScript, the color is a global variable; not a string. That’s important, because if you try to use the variable’s name in OpenLaszlo 4.2, you’ll get a Debugger warning:

ERROR @colors.lzx#35: reference to undefined variable ‘red’

That’s because all the colors are now neatly arranged in an array called lz.colors. So in 4.2 you would write:

myview.setAttribute("bgcolor", lz.colors.red);

Another benefit of the colors all being grouped in an array - as opposed to being global - is that you can loop through them. I wrote the following application to display the colors and color names available in OpenLaszlo 4.2.

Click the button to render the color boxes. Move your mouse over the boxes to display the name of the color.

The code is below:

<canvas width="460" height="460" proxied="false">

    <class name="colorbox" width="30" height="30" clickable="true">
        <attribute name="colorname" type="string" />
    </class>

    <class name="colornameoutput" extends="text"
           font="Helvetica, Arial, sans-serif"
           fontsize="24" fontstyle="bold">
        <attribute name="updateDel"
                   value="$once{new lz.Delegate(this, 'displayColor')}" />
        <method name="displayColor" args="c">
            this.setAttribute("text", "lz.colors." + c.colorname);
        </method>
    </class>

    <simplelayout axis="y" spacing="10" />

    <view name="colorboxes" width="100%">
        <wrappinglayout spacing="0" />
    </view>

    <colornameoutput name="outputText">
    </colornameoutput>

    <button options="ignorelayout" width="80%"
            height="80%" align="center" valign="middle"
            font="Helvetica, Arial, sans-serif"
            fontsize="13" fontstyle="bold">
            Show Me The Colors!
            (Be patient, it takes a moment).
        <handler name="onclick">
            this.setAttribute("visible", false);
            for (var i in lz.colors) {
                var colorValue = lz.colors[i];
                var attrs = {bgcolor: colorValue, colorname: i};
                var v = new lz.colorbox(colorboxes, attrs);
                outputText.updateDel.register(v, "onmouseover");
            }
        </handler>
    </button>

</canvas>

What’s new is that the Vortex has now been integrated into Laszlo Webtop. You can check it out at www.gowebtop.com. You do need an account for gowebtop.com, but it’s fairly quick and free.

Vortex Application in Laszlo Webtop

What’s interesting to OpenLaszlo developers is:

• The Vortex application is completely dynamically-skinned. The components in the Vortex can be enabled, disabled and re-ordered without recompiling the SWF. All resources in the application get loaded over HTTP when the application initializes. This performs surprisingly well.
• You can plug an OpenLaszlo application into Webtop relatively easily. Webtop provides the notion of applications, as well as windowing/docking/undocking behavior. And, Webtop includes some applicaitons that people use the most (Mail, Contacts, Calendar).

Although Webtop does offer a service that proxies and optimizes data transactions between the client and data stores, you don’t have to use it; you can just compile an OpenLaszlo application that uses datasets in the normal way into Webtop, and run it alongside the existing applications.

SWF9 support may not sound like a huge deal to many people - it’s just a matter of keeping up-to date with the newer version of Flash, isn’t it? Well, not exactly. The difference between SWF8 bytecode and SWF9 bytecode was significant. So big, in fact, that Adobe included two completely separate runtimes in Flash Player 9: one for running the new SWF9 bytecode, and a separate one for running SWF8-and-below bytecode. In other words, the SWF9 capability is a pretty big deal.

Just how much of a performance gain does the new runtime offer? A few months ago, while writing a post about optimizing data for Lzx (OpenLaszlo Performance Tip: Attributes, not Nodes), I found that the then-beta SWF9 runtime in OpenLaszlo was as much as 3.7 times faster than the SWF8 one, at loading and parsing XML data. At the time, much of the functionality was still missing from the 4.2 branch, so data loading was the only behavior I could test.

With 4.2 available, I wrote a simple test that measured how long it took to instantiate 100 windows:

<canvas>

    <text id="output" fontsize="36" />

    <class name="mywindow" extends="window" width="300" height="200">
    </class>

    <handler name="oninit"><![CDATA[
        var dStart = new Date();
        var j:Number = 0;
        var xpos:Number;
        var ypos:Number;

        for (j=0; j<100; j++) {
            xpos = Math.max(150, Math.random() * canvas.width);
            ypos = Math.max(50, Math.random() * canvas.height);
            new lz.mywindow(canvas, {x: xpos, y: ypos});
        }
        var dEnd = new Date();
        var timeTaken = dEnd.getTime() - dStart.getTime();
        output.setAttribute("text", timeTaken);
        ]]>
    </handler>

</canvas>

The results for creating 100 windows in OpenLaszlo 4.2.0 are:

• SWF8: 6,042ms
• SWF9: 1,073ms

That’s 5.6 times faster - even more dramatic than the results from the data loading test!

Surely all OpenLaszlo developers will now rush to recompile their applications to SWF9; all it takes is appending ?lzt=swf9 to the request, doesn’t it? Unfortunately, it’s not that simple. Moving from OpenLaszlo 4.0 to 4.1 involved a lot of language changes, specifically in anticipation of SWF9. I wrote about this a while back. Then, moving from OpenLaszlo 4.1 to 4.2, there were a few more changes, mainly because icompatibilities were found after 4.1 had been released, and in-depth development had started on supporting the new runtime. As an example, the <script> tag shouldn’t be used in SWF9. It actually partly works, but causes confusing errors. Better replace it with <handler name=”oninit”>.

Happily there are some resources and tools for developers needing to migrate their applications. There’s an OpenLaszlo wiki page on Runtime Differences, which should be your first stop. It describes how to use the Perl migration script that (in theory) updates your code for you. Remember that it may not catch everything. It’s hard to anticipate every manner in which developers will use a platform, so please be patient and provide any feedback on issues you hit on the forums or mailing lists.