OpenLaszlo 4.0.3 was released to the web today. This is a minor release resolving more than 70 issues reported against OpenLaszlo 4.0.2. Download it here or play with it here (flash runtime) or here here (dhtml runtime).

Full details, including a list of fixed bugs, are available in the Release Notes.

Many of the issues addressed in this release were reported by the OpenLaszlo community, and some of the fixes were contributed by the community. Thanks to everyone who took the time to try out OL4 in SWF or DHTML and report your experiences to the mailing list or forum, and a particularly warm thanks to those of you who filed bugs. This release also has several known bugs in IE7/DHTML, which were discovered just as we were calling the release:

• Views clip their contents when opacity changed in IE7 DHTML This an issue with the IE7 renderer. The workaround is to not set the width/height of the container that has alpha (so the view system can resize it to its contents) or set the width/height to be bigger than its contents. See the JIRA bug comments for an example of this workaround, and this msdn article.
• LPP-4242 Controls go to disabled state when outer view opacity set in IE7 DHTML
• LPP-4244 Mouse handling busted in IE7 DHTML

We have fixes in hand for these bugs, which you can get in the legals nightly builds starting at r5785.

Note that while quality continues to improve, we do not recommend 4.0.3 for use in production environments yet, in part due to the known issues listed above. Release 4.1 is the planned milestone at which we will recommend upgrading production deployments from 3.x.

The community developer base is getting busy! We're seeing lots of bugs reported by the community -- really good bugs, filed in the bug database with executable test cases, version information, browser information, and clear descriptions. Amazing and wonderful! Big kudos to Geoff Crawford, André Bargull, Robert Yeager, Srini Raja, and the rest of the bug contributors. Filing good bugs is the easiest way for you to contribute to the Open Laszlo development effort. We do actually fix community reported bugs, and we do take contributed bug fixes. Our upcoming release, 4.0.3, is almost entirely bug fixes, many of them reported by external developers. Keep those bug reports coming; you're helping to improve the software.

Since John and I keep getting inquiries about changes made in the OL4 documentation, and many of you are likely to be using OL4 sooner or later, I thought I'd send out one message in the hopes of providing a single point of discussion.

We had four primary goals with the OL4 documentation:

1. Support the ability to mark content that is runtime-specific. As you know, OL4 supports multiple runtimes (Flash and DHTML, more to come), and while the core OpenLaszlo APIs are the same across all runtimes, there are differences where we can support extra features or where we haven't yet gotten to strict parity. The documentation must reflect this.
2. Improve maintainability of the doc tools and the documentation. The OL3 toolchain was extremely proprietary, difficult to understand, and thus had suffered from poor maintenance. In addition, it was possible for the reference material to drift relative to what was implemented in the code, and there were other areas (such as the schema) where we were essentially inviting inconsistency. We decided that it was a very high priority to rebuild the doc tools around standard technologies wherever possible, in order to simplify maintenance, ensure accuracy and consistency, and to better invite participation from the community.
3. Make it easier to accomplish several important goals: invite community participation in writing and maintaining the documentation, reuse the tools for other projects, localize the documentation, and maintain the live embedded examples.
4. Produce a unified index across all the documentation.

With these goals in mind, we rebuilt the entire documentation tool chain around two technologies. The first is a homegrown tool called "js2doc" which uses the JavaScript parser in our compiler to extract precise information about the APIs actually found in the source, merges that information with annotations and comments, and generates documentation in an XML format. This tool, which I built, is based on the standard javadoc tool and uses (as much as practical) the same conventions used by javadoc.

The second technology is an open source standard called Docbook. This is currently the most widely adopted documentation standard on the market and is extensively integrated with documentation publishing systems of various kinds. (The OL3 documentation used Docbook, but only as an internal tool.)

Docbook uses a pipelined workflow. Essentially, content is produced in Docbook format, and then transformed by XSLT into any of a number of destination formats. The workflow is optimized for static generation of a traditional book (either a single PDF file or a conventional, static html document web), but before adopting Docbook we made sure that there were solutions available for more dynamic publishing styles. John and I wanted to make sure that multi-pane navigation from OL3 was possible, as well as full-text search and other nifty web publishing techniques found in the online documentation for other languages (e.g. Perl).

Docbook has a clean localization story, and is well itself well documented (there's even an O'Reilly book for it!).

The reason I am writing this email is that John and I have found ourselves repeatedly explaining our decision to take an architecture-focused approach to this redesign rather than immediately providing all of the user-visible features from OL3. Our conclusion, based on years of interaction with the community, is that it is relatively easy to attract external contributors to the documentation -- to write cookbooks, to localize, to edit, to improve the tools -- *as long as* the barriers to entry are relatively low. By acting to simplify and normalize the doc toolchain, we open the door to much greater participation from the community. And by making it possible to reuse the tools for other projects, we further increase the potential for real support commitments. The tradeoff is that a few user-centered features are not implemented in the first version of the OL4 documentation, but we absolutely plan to provide those features in the future.

As you approach the OL4 documentation, you are likely to have the following questions, and we'd like to take the time to provide you with answers. Our purpose is to inform, and to open the door to broader input about priorities, not to shut down debate or questions.

Q. What happened to the left-side nav bar?

A. The simplest Docbook publishing mode is to generate a book-style html web, with a table of contents. Our plan from the beginning was to rely on existing doc publishing tools such as Apache Cocoon to provide more sophisticated navigation tools such as multi-frame navigation.

Q. What about search?

A. Search is not currently available within the new documentation. However, we have added a search box to http://www.openlaszlo.org/documentation that provides targeted search of documentation for a range of different OL versions, including OL4. Our current plan is that in-page search will arrive with adoption of a live publishing solution such as Apache Cocoon.

Q. Where is the class/tag index?

A. Due to a bug in the XSL tools for Docbook, automated construction of secondary indices increases the time for generation of the primary index from 8 minutes to 80 minutes. Until a fix is found for this bug, or a maintainable alternative is built -- and a hand written class index is not maintainable -- we have left this feature out of the documentation. But it is a goal to provide this index.

Q. Why not implement user comments like in the Perl documentation?

A. We like the idea of comments, but are also wary of the problem of staleness. (Stale info in comments is no more helpul than stale or incorrect info in documentation). You also get the problem that you have two virtual forums instead of one, which leads to confusion. We're considering some kind of commenting mechanism whereby relevant forum topics would be listed within each documentation page. Philosophically, we think the right approach is to keep the docs current, rather than to have them stale and corrected in the comments. We're looking to set up a process whereby the community can help us fix the documents themselves, not merely comment on them. We welcome input.

Q. Can I use the new toolchain for my own project?

A. Absolutely! The new toolchain is much more reusable than the old one.

Q. How can I get involved?

A. Email John Sundman (jsundman openlaszlo dot org) or myself (jgrandy at openlaszlo dot org) and we'll get you involved.

Bret Simister and I spent this weekend hacking at iPhoneDevCamp, occasionally coming out of the code trance to tell people, "Open Laszlo compiles to standards-compliant DHTML that works well in every major browser, including Safari on the iPhone." Starting from scratch on Friday at 6 pm, we built a little app called NewsMatch using the Open Laszlo platform. We love the swoosh, zoom, whoosh feel of the iPhone ui, so we started with an app concept with a lot of room for swooshing. We also wanted to do something that wasn't completely silly; just a little silly would be fine. Bret suggested a matching game about the news, so off we went... I found an rss stream with photos for every item (thanks yahoo!), cached the xml locally with
curl http://rss.news.yahoo.com/imgrss/441 > news.xml, then set about showing it in OL. (Tutorial on how to do this in another article soon.) Poof, twenty lines or so, there's an RSS reader. Open Laszlo is seriously sweet for building applications around xml data.

I used the SOLO deployment wizard to create a set of files that I could post on the web, to view it on the iPhone. The SOLO deploy wizard gives me an html wrapper, main.lzx.html, into which I dropped some metadata:

      <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;">

This defeats the iPhone browser panning/scaling; the double-tap and the pinch/zoom-to-scale work really nicely for viewing a normal html page on the iPhone, but we're authoring this application directly to the iPhone screen size, so we don't want to permit any zoomies that we don't explicitly request.

That viewport tag is the only change I had to make to Open Laszlo's DHTML output to make it look great on the iPhone. Fonts, views, opacity, animation, events, handlers, custom classes, data binding... it all just works.

I added some game logic using vanilla javascript, and Bret buffed up the interface and animation, to hit the swoosh sweetspot. At that point It was 10 am Sunday and we still had four hours before the Hack-A-Thon ended. We did a few more tweaks to improve performance on the low-low-low bandwidth EDGE netowrk:

• We deferred loading the images until after the main ui has slid in, by adding an onstop handler to the intro animation.
• We made a custom splash in DHTML, to show while the rest of the application downloads. This was another tweak to the html wrapper page, this time in the lzsplash div. We just added a few divs that match the NEWS/MATCH title screen, for a seamless transition from vanilla DHTML to OpenLaszlo-generated DHTML.

That's all; it's up and running, in time for the Hack-A-Thon demos. Since then I've made a few small improvements, but what you see here is almost entirely the product of two days work by two people using Open Laszlo. The whole thing is around 400 lines of code.

View the source for this application or download it with
svn co http://svn.openlaszlo.org/sandbox/ben/smush.

From the viewpoint of a user interface enthusiast, Apple's iPhone is a deeply fascinating product. Whatever its flaws as a mobile phone, the UI design represents the state of the art in what we at Laszlo call the "cinematic user experience" -- meaning an interactive experience in which animation, motion, and visual continuity are used to enhance usability. The sheer amount of detail work that has gone into every aspect of the UI, and the way in which the GUI has been put at the center of the experience, mark this product as unique in its category.

If you're an OpenLaszlo developer looking at the iPhone UI, you'll be thinking about how its various transitions and interactive elements would be represented in LZX -- you can almost see constraints, animators, and states behind its effects. In fact, the iPhone UI is exactly the kind of expressive, cinematic experience that LZX was made to enable -- and I bet it would have been radically simplified if implemented in LZX rather than native code.

Which raises the issue: what about using OpenLaszlo to develop for the iPhone? Well, in some ways this is a very natural fit. Besides enabling the style of UI that the iPhone has embraced, OpenLaszlo 4 works very, very well with the Safari 3 (desktop) browser, and does not require Flash or Java to deliver rich applications -- which is great, since the iPhone has neither Flash nor Java.

It is positively amazing that some OpenLaszlo applications work correctly without alteration on the iPhone. I don't think any other RIA platform can claim this level of functionality; certainly none that depend on Flash or Java. (Don't expect a Flex app to work on this device!) The momentum behind "mobile Ajax" is real -- not only with Apple, but also with Nokia -- and validates our choice of DHTML as a target runtime. Flash-free RIAs definitely have a bright future, especially on mobile.

But, this is very much an evolving story, and as things stand today, the iPhone browser introduces unique challenges that are not present in the desktop version of Safari. These issues are not OpenLaszlo-specific, and to varying degrees are shared with other JavaScript frameworks and RIA platforms. Although the iPhone browser is a "real" browser compared to previous generation mobile browsers, is does deviate from desktop browsers in some respects.

Last week, there were a series of announcements from companies working in the Ajax/RIA area that were premature -- they didn't have iPhones in hand, and just assumed that the iPhone environment and the Safari (desktop) environment were the same. ("Hey, the iPhone supports Ajax. Our tool supports Ajax. So we're done. Let's issue a press release!"). Nice try, but the realities are a bit different, at least for the time being:

• Poor JavaScript performace. While we have not yet done any formal profiling of applications running on the device, it appears that JavaScript execution speed, as compared to HTML rendering proper, is disproportionately slow. With its 667 MHz CPU, rendering speed is quite good, as you would expect on a machine of this speed. JavaScript execution speed, by contrast, feels *much* slower. The result is that OpenLaszlo applications (however simple) take unexpectedly long to start once loaded on the iPhone. We're hoping that this is temporary and will be addressed in a future update; but perhaps there is a systematic reason for this that will prevent near-term improvement.
• Limited JavaScript memory allocation. There is a 10MB limit on JavaScript object allocation, which sounds like a lot until you consider that OpenLaszlo applications are entirely JavaScript-dependent, and make little use of statically rendered HTML. To put this another way: even an object as simple as a button in OpenLaszlo requires a significant number of JS objects to be allocated, initialized and positioned via script -- which is very different from a typical Web site. The net result is that only relatively simple OpenLaszlo applications will launch on the iPhone for the time being.
• Input field problems. As users have been reporting, the iPhone's Safari browser does not work correctly with certain text input fields on certain websites. This is apparently the result of the unconventional event sequences that the browser sends to the fields. As things stand, text fields in OpenLaszlo applications do not take any input. This may be fixable in OpenLaszlo, but a systematic fix in the iPhone browser would be preferable.
• Native UI controls vs. synthesized UI controls. OpenLaszlo displays UI controls (components) the same way everywhere, regardless of runtime environment or host OS. This philosophy has advantages, in that a UI component created in LZX will act and work the same everywhere, and is portable across runtimes. It also has limitations: where Apple, for example, does special things with menus on web pages (which are quite nice), an OpenLaszlo application running on the iPhone will not take advantage of this behavior, since the browser does not see an OpenLaszlo menu as a menu. This is not so much an OpenLaszlo bug as a design approach that works against OpenLaszlo in this particular case.
• Finally, the trickiest problem: UI paradigm incompatibilities. The iPhone browser has a handful of UI features that have the effect of making certain UI gestures impossible to capture within a browser-based application. The browser "steals" drag and double-tap gestures, so that a browser-based application running on the iPhone cannot rely on either drag-and-drop or on double-click. These gestures (and others, like "pinch") would have to be passed through to the browser in order for the developer-created app to see them; but this would come at the expense of Apple's ability to guarantee the integrity of the experience.

Obviously these are the early days of iPhone, and we should expect changes. As things stand, iPhone is not a supported target for OpenLaszlo; while most functions do work correctly, there are significant limitations, and some of those limitations are limitations of Apple's software (at least in its first revision), and others are more fundamental to iPhone UI environment, and will require iPhone-specific interaction design -- i.e., drop the drag-and-drop.

That being said, a group from Laszlo is attending the iPhoneDevCamp this weekend (hey, we're even a sponsor!), and we're hoping to give OL a solid workout in the iPhone/Safari environment. If we're lucky, something cool will come out of it, and perhaps a better sense of where things work and where they don't. But it seems like a safe bet that no matter what happens this weekend, we (along with other Ajax development platforms) will be very dependent on Apple to upgrade its JavaScript performance before the iPhone becomes the truly awesome OpenLaszlo environment that it deserves to be.

That headline got you interested, right? "Finally, they've implemented a better rich text editor!" Sorry, but no... we want you to implement a better rich text editor.

Open Laszlo 3.4 has a rich text editor, but it's not very good. It's inherently limited by Flash Player 7's support for rich text, which seems to have been designed to display rich text, not to support interactive text format editing. With the DHTML runtime for Open Laszlo 4, we're free of the constraints of the Flash player(s), and into a whole new frying pan: the constraints of the browsers. There are lots of other projects which work in that particular frying pan; in particular, other development efforts have already written javascript-based rich text editors. (TinyMCE from moxiecode comes to mind.) Some of these are free, open, and cross-browser-capable. Combine one of those with the Open Laszlo <html> tag, and we could finally have a good rich text editor in Open Laszlo.

This is a good place for a community contributor; could you integrate an existing DHTML rich text editor into the Open Laszlo 4 platform?

To do this, you'd have to learn some cool new tricks, which haven't been documented much yet: the <switch> tag, the #pragma compiler hint mechanism, the runtime-specific compile-time constants, and probably some stuff we haven't figured out how to do yet, like including a third-party library. You'd help us design and develop the platform support that developers will need to integrate a third-party javascript library, and you'd implement the first dhtml-specific extension. And you could choose which third-party editor to integrate.

Anybody interested? Write to me: ben at laszlosystems dot com.