OpenLaszlo 4.0 Release Notes

Table of Contents

• Introduction
  • Overview
  • Who should read these Release Notes
  • Getting Involved
  • Roadmap
  • Credits and Acknowledgements
  • Further Resources
• Overall Status
• Obtaining OpenLaszlo 4.0
• Developing with OpenLaszlo 4.0
• Compatibility
• New Features
• DHTML Runtime
• Known Issues with This Release
• Colophon

Introduction

Welcome to OpenLaszlo 4.0. We invite you to start developing against our new DHTML runtime and to explore the other improvements that have been made since OpenLaszlo 3.3. This is the first fully-qualified release of OpenLaszlo 4.

(Note that OpenLaszlo 4 was known during pre-beta development as project "Legals".)

Overview

Relative to 3.x and earlier versions, OpenLaszlo 4 incorporates a major re-architecture of OpenLaszlo to support multiple target runtimes and provides compatility for two runtime families: Flash, as in previous releases, and browser native DHTML. With this release, OpenLaszlo becomes a true Ajax development platform.

OpenLaszlo applications compiled to DHTML consist of compiler-generated HTML, JavaScript, and CSS files, and they run without use of plugins within modern web browsers. Applications compiled to the Flash runtime consist of a single SWF file and run within one of the various Flash players.

As part of the process of re-architecting OpenLaszlo, we also did a major overhaul of our tools infrastructure and build processes. Major build tools have been upgraded, the use of Jython all but eliminated, and the tools used to build the Reference Guide have been rewritten.

One significant feature (the SOAP RPC protocol) has not yet been ported to DHTML, and there are issues with a few other components (notably Charting and Graphing). In addition, the incubator components have not been tested with OL4. Details are immediately below, as well as in the Overall Status section, and in the Developing with OpenLaszlo 4.0 section.

Flash Compatibility

OL4 is compatible with versions 7 through 9 of the Adobe Flash Player: 7 (v. 7.0.60.0 or later), 8 (v 8.0.22.0 or later), and 9. Earlier versions of Flash Players 7 and 8 are not recommended because of a security vulnerability in earlier versions of those players. Support for Flash Player 6 has been removed from this release because Adobe declined to fix the same security vulnerability in that version of the player.

Note that Adobe Flash Player 9 contains a new runtime, as well as a compatibility mode that allows it to run older content unchanged. OpenLaszlo 4 runs within Flash 9's compatibility mode. Native support for the new Flash 9 runtime may be available in a subsequent release.

Browser-native DHTML Compatibility

Our DHTML support covers three of the most popular browsers currently available: Firefox (1.5 and 2.0), Microsoft Internet Explorer (6 and 7), and Safari 2. Some other browsers are not officially supported but seem to work fairly well, including Opera 9. Older browsers such as Firefox 1.0, Netscape, and Microsoft Internet Explorer 5 on Windows and Macintosh, are missing critical features and will not run OpenLaszlo applications at all. See the browser compatibility table for a current list of supported browsers.

OL4 does not include the Orbit runtime; watch Sun's Orbit project page and the OpenLaszlo Orbit page for news on Orbit.

Who should read these Release Notes

We imagine three potential audiences for this release:

• developers porting an existing OpenLaszlo app to OL4,
• developers learning OpenLaszlo from OL4, and
• contributors to the OpenLaszlo platform itself.

There is the added dimension that some developers may be primarily interested in one runtime or the other. OpenLaszlo 4 provides a robust cross-runtime language and application framework, so we hope that any runtime preference is driven by either delivery requirements or by the need for particular runtime-specific functionality.

We have tried to structure these release notes so that each audience may readily come up to speed and find answers to their questions. Whatever your perspective, please read the Overall Status and Short Tour sections before diving into the more detailed information that follows them.

Getting Involved

If you would like to get involved contributing to the development of OpenLaszlo 4, please begin by visiting the contributor's FAQ. We are eager to work with you to match your interests and skills to the most current needs of the project.

Post to laszlo-dev@openlaszlo.org with questions and comments. Please report bugs, especially regressions, to our bug database. We encourage you to file reports of reproducible, testable bugs. Please try to put as much relevant information as possible in your submissions. A special place in nirvana awaits those who file test cases in their bug reports.

Roadmap — What's coming next for OpenLaszlo

Current information on our plans for future development of OpenLaszlo is available on the OpenLaszlo Wiki here.

Credits and Acknowledgements

OL4 includes contributions from the OpenLaszlo team at Laszlo Systems, Inc., and from the wider OpenLaszlo Community.

The community has reported many bugs, some of which have been fixed. Thank You.

Many thanks to the members of the Dojo community, in particular Alex and Brad. You've blazed many trails for us, and in particular, dojo.flash is quality stuff. Thanks also to Peter-Paul Koch for his excellent compendium of browser quirks at quirksmode.org. And special thanks to Amy Muntz, without whose enthusiasm, support and encouragement we probably wouldn't have achieved this milestone.

Further Resources

Further Information about OpenLaszlo in general and OpenLaszlo 4 in particular maybe found in the places listed below. Keep in mind that "legals" was the code name for the OpenLaszlo 4 project; you will see evidence of that name in places such as the wiki and in some directory names.

• The OL4 project page.
• The OL4 wiki page
• The OpenLaszlo Forum, especially the OL4 topic
• The laszlo-user mailing list, for developers using any version of OpenLaszlo
• The laszlo-dev mailing list, for contributors to the platform

More general information about OpenLaszlo can be found on the OpenLaszlo home page and on the OpenLaszlo wiki.

Overall Status

OL4 is a fully qualified release. The vast majority of the Flash runtime has been brought to DHTML, and the every demo or example that does not rely on a Flash-specific feature is now available cross-runtime.

To get familiar with the new world of OpenLaszlo 4, we suggest that you spend some time playing with the OpenLaszlo Explorer, particularly the major demo applications and Laszlo in Ten Minutes. Note that everything within Explorer, including Explorer itself, runs in both Flash and DHTML. There are buttons at the bottom of the Explorer Welcome page that reload in either runtime.

Obtaining OpenLaszlo 4.0

OpenLaszlo 4.0 is available from http://www.openlaszlo.org/download

Archives of builds

Archived source for all releases are available in our Subversion repository here.

Installers for recent 4.x builds are available at http://svn.openlaszlo.org/openlaszlo/tags/4.0.0

Developing with OpenLaszlo 4.0

Depending on your background and whether you will be developing a new OpenLaszlo application or porting an existing one, you will want to take different approaches to your task.

Developing New OL4 Applications

If you are new to OpenLaszlo, you should start by going through Laszlo in Ten Minutes and then the tutorial section of the Developer's Guide.

If you're compiling to SWF, certain DHTML text manipulations are not available; if you're compiling to DTHML certain other features are not yet available. If you want to have the option run across both platforms, you may either write to the "lowest common denominator" or conditionalize your code according to the value of a compilation flag.

Porting from OpenLaszlo 3.x to OpenLaszlo 4

If you're upgrading existing applications to OL4, the most direct path will be to port first to the Flash runtime, and the get your application running in DHTML as a separate step.

There should be very few code changes required to port your application from OL3 to OL4/Flash, because the runtime behavior of the two is very similar. Be aware, however, that some changes may be required.

Although getting rid of derefenced null pointers is not strictly required, now would be a good time to rid your code of them. They may be disallowed on short notice at some point in the future, and, as noted, they preclude running in DHTML.

There will be very little change in the JavaScript used in script blocks and method definitions in OpenLaszlo applications. The main changes to JavaScript in support of SWF9 and ECMAScript 4 are in the LFC sources to take advantage of the faster class system in OpenLaszlo 4. This change will automatically be handled for JavaScript in LZX code.

For applications being compiled to DHTML, in addition to the above-mentioned issue of dereferenced null pointers, SOAP/XML-RPC, and CSS, there are a number of considerations in porting from 3.x SWF to OL4 DHTML. The big issues to pay attention to are:

• accessing multiple runtimes
• no SWF assets in DHTML
• no embedded fonts
• only partial support for <drawview>
• changes to how events are implemented
• state changes
• using compression to reduce download size

Strategies for handling these changes are discussed below. Also, see Ben Shine's very helpful porting checklist, summarized below.

Compatibility

OpenLaszlo 4 is compatible with two families of runtimes: Flash and browser-native DHTML. The level of support for particular Flash players and browsers is indicated below, rated in a fashion similar to the Yahoo Graded Browser Support scheme. A few other runtimes are listed as well.

Generally speaking, OpenLaszlo 4 should work within any browser that supports ECMAScript v3, DOM Level 2, and CSS 2.1. All browsers have quirks, however, and QA resources are finite, so some generally-conforming browsers may be more compatible than others.

New Features

This section lists significant new features to be found in OpenLaszlo 4.

Multi-runtime Architecture

As explained above, the entire runtime architecture has been overhauled. The most important new developer-visible feature is the change in how runtime can be selected when an OpenLaszlo application is fetched from the server.

New DHTML Runtime and new URL parameters

As part of the architectural overhaul, we have created a new version of the client runtime (LFC plus kernel). To invoke an application compiled for DHMTML, use the ?lzr=dhtml query.

The ?lzr parameter selects the runtime. Your choices are swf7, swf8, dhtml. The default is specified in lps/config/lps.properties as compiler.runtime.default. The default runtime selector is swf7.

The ?lzt parameter is the 'request type', in general what kind of 'wrapper' page will be generated around your application. Your choices are: app_console or html. app_console is the developer console, html is your app in an html page. The latter can be used as a model for embedding your app in a custom page, or you can simply embed using an iframe:

<iframe src=".../app.lzx?lzt=html"></iframe>

The default for ?lzt is specified in lps/config/lps.properties as defaultRequestType. The default value is app_console.

Mnemonics:

• lzr - Laszlo Runtime
• lzt - Laszlo request Type

JavaScript language improvements

The class system underlying the Laszlo Foundation Changes has been extensively redesigned. This change is transparent to LZX programmers; it mostly concerns those writing code at the LFC level.

Before OL4, we used a prototype-based class system. With OL4, we have switched to an inheritance-based class system that tracks the emerging ES4 standard. These new language features have been implemented in the LFC core to support (and extend) JavaScript 2 `class` declarations portably. LFC developers can now write JavaScript 2 `class` declarations, rather than creating their classes using JavaScript 1 prototypes. The JavaScript 2 `interface` declaration is supported, but not enforced (that is, there is no compile or runtime checking that a class actually implements an interface).

We have extended JavaScript 2 to support `mixin` declarations (see below). However, Mixins are not exposed or documented for use in application programs in in OL4. Eventually, we will expose `mixin`s at the LZX API and the application programmer will be able to use that feature to modularize their programs. We feel this will be highly beneficial in the design of UI components which tend to have shared behavior in patterns that single-inheritance subclassing cannot easily describe without a lot of duplicated code.

See [BrachaCook90](http://portal.acm.org/citation.cfm?id=97982&coll=portal&dl=ACM) for a formal definition of mixins. Informally, mixins are 'interfaces with implementation'. They take the same form as a `class` declaration, but are introduced by the keyword `mixin`. They are added to a class similarly to an interface, but with the keyword `with`. They are allowed to add methods and fields to the class they are mixed in to.

The new class regime allows us to support the LXZ class system and Javascript 2 `class` declarations in a portable fashion across more runtimes.

For a description of the new class system, see PT Withington's blog entries in the OpenLaszlo Project Blog: Class-based OOP in JavaScript done right Circles and Arrows, which provides a pictorial view of the new class system

lz.[tagname] classname convention

The preferred normalized form of class names is lz.foo, where foo is the name of a tag.

In earlier versions, there was an asymmetric mapping, often of the form LzFoo <—><foo>, as in LzView and <view>, and there was a distinction between LFC classes and user-created classes. These old forms will still work but at some point will probably be deprecated. The new form is consistent across LFC classes and user-created classes.

Other Script Language changes

See wiki.openlaszlo.org/ECMA3_Compatible_Languages

In SWF earlier than SWF7, there was a difference between certain ActionScript semantics of null, undefined, equals, and not-equals, and the JavaScript definition of those values/keywords/comparisons. With SWF7 those semantics have been normalized; semantics of comparisons are now the same in the SWF runtime as in the DHTML runtime.

With OL4 we have added support for the JavaScript "in" operator.

"static" is a reserved word in javascript 1, but the compiler didn't complain about it pre-OL4. Now using the word static causes a compiler error.

      <canvas>
        <script>
            var o = {};
            o.static = null; // this line gives a compilation error: test-static.lzx:7:11: Syntax error: the token "static" was not expected at this position.
        </script>
      </canvas> 
    

Wrapper pages and JavaScript include files

The HTML wrapper pages have been cleaned up and simplified for OL4. Browser/JavaScript bridge and Flash embedding code has been completely rebuilt with dojo.flash. Related to LPP-2664 update deployment wrappers for OpenLaszlo 4, LPP-3181, and LPP-3182.

SWF and DHTML runtimes now share a single JavaScript include (lps/includes/embed-compressed.js) containing all necessary code for embedding a SWF or DHTML application.

In most cases developers never need to familiarize themselves with these APIs because the LPS server's wrapper system automatically generates the appropriate HTML.

Resource Loading

OL4 includes a major rewrite of the resource loading system in the compiler and the server. These changes should not be visible to the application developer at all. This change affects loading resources both at compile time and at runtime. It changes how the resources are found on the server or on the filesystem.

SOLO in DHTML

This release contains support for SOLO deployment with the DHTML runtime. We recommend use of JDK 1.5 instead of JDK 1.4 when using the SOLO deployment tools.

Cascading Style Sheets (CSS)

We are working on a fully-dynamic, integrated implementation of CSS for OpenLaszlo application development. An initial implementation with limited functionality and very little integration into the LFC or the Components is included in this release. Please note that this feature is in progress, and will not be available for use in typical OpenLaszlo applications until a post-4.0 release.

Audio - Video

Support for streaming audio and video media in applications compiled for the Flash Player is available in OpenLaszlo 4. See the Developer's Guide.

Debugging Improvements

The Debug class now supports several new methods for formatting and outputting information. See the Developer's Guide

New Test Systems

The test directory does not ship in OpenLaszlo distributions and the various test files used internally have moved around in the repository. Our favorites now live in test/lfc/perf, test/lztest, test/lzunit, and test/smoke. Regressions have been moved to a separate repository at http://svn.openlaszlo.org/test/bugs/

lztest

lztest is a tool for testing the compiler and the LFC. Tests for it are not included in the distributions, but they are run for each build. lztest allows the same test code to be executed in SWF, in DHTML, or from a command line by using the Rhino runtime. The command line lztest facilitates automated build testing.

lzunit

lzunit has been updated to work in OL4B1 in the SWF runtime and the DHTML runtime.

megatest

In the live source tree, we have added a "megatest" target which runs all the tests. This is used in the automated build process; application developers will not typically use it, but it can be useful when diagnosing configuration or platform issues.

xmlunit and JUnit

JUnit tests exist for some of the compiler and some of the doctools. The doctools also use xmlunit for unit testing. Neither of these are visible to application developers.

New implementation of the Reference Manual

The documentation tools have been re-implemented in order to to make them easier to maintain and also to give us more possibilities for arranging and accessing the data in the Reference Manual. Eventually, this will allow us to provide better cross-referencing, better indexing, more user control over presentation of information, and more options for printing and displaying the documentation.

However, this tools work is not yet complete and the Reference Manual is a work-in-progress. We expect steady improvements in the quality of the documentation over the next few releases.

Tools Improvements

The tools we use to build, test, and analyze OpenLaszlo have matured significantly with OL4. We have changed to using Subversion from Perforce, for source control, in order to enable a more open development process. The build is now based on ant 1.6.5, rather than ant 1.5. We have created a new testing tool, lztest, for automated testing, without dropping lzunit, for application- and component-level testing. We have created a suite of benchmarks and benchmark analysis tools.

Build Environment Changes

This item applies only to developers building from source.

We support building and running under Java 1.4 and 1.5. We recommend building with Java 1.5. We haven't tried 1.6.

We now require Subversion 1.3 or later and ant 1.6.5 or later to build from source. See subversion build instructions on the wiki

DHTML Runtime

DHTML in Internet Explorer 6 is problematic, as is well-known by the web development community. Kernel and LFC support for IE6 is the most likely to have bugs. All the bugs we know about are in the JIRA base, of course. We would appreciate your help in locating any others that may be there.

Dereferencing Null Pointers

The Flash runtime is permissive about dereferencing a null reference and getting properties on an undefined object. DHTML blows up if you do this. By "blows up" we mean that each DHTML browser crashes or hangs in a different way when the application code dereferences a null pointer. Lots of legacy code doesn't check for null.

In JavaScript you are allowed to ask for a non-existent slot, but not for a slot on something that is not an object. Therefore, don't say foo.bar unless you know that foo is an object. If you know foo is either an object or null, you can say if (foo) before you say foo.bar. If you don't even know that, you would need to say if (foo instanceof Object).

Furthermore, in DHTML you cannot reference a non-existent variable. Therefore you should declare all your variables. In SWF, you could get by without declaring them, and they would just appear to be `undefined`. In DHTML, it is an error to refer to foo if you have not first said var foo.

If you are trying to make some legacy code work, you can ask if ('foo' in global) to see if foo had been declared, but that's sloppy. It's better to inspect your code to make sure that all variables are initialized before they're referenced. Even if you're not planning to compile to DHTML, you should use the more conservative style, as this will enhance maintainability and allow you to retarget for DHTML in the future if you decide to do so.

Debugging in DHTML

For debugging the DHTML runtime, we recommend the FireBug extension to FireFox. If Firebug reports an error (with a little tiny red X in the bottom right hand corner of your firefox window) then there is probably a bug in your code or an OpenLaszlo bug. The errors reported by FireBug can be very obscure, but they usually happen when you are dereferencing a null pointer.

Firebug is more useful if you compile your DHTML application under debug mode (debug=true) so that method names show up in firebug stack traces. Dropping down the arrow next to an exception in firebug will show a complete stack trace - often helpful for tracking down the root cause. Please file bugs with a stack trace if possible!

Debugging is broken in safari. You can work around it by setting:

      compiler.debug.safari=true
    

in WEB-INF/lps/conf/lps.properties

But when you do that, you lose the ability for FireBug to give you meaningful backtraces which is why it is off by default. Safari's JavaScript parser croaks on legit JavaScript. Therefore it's best to debug in Firefox. Or you can download the nightly of WebKit. Safari is fixed there, and we presume will be fixed in Leopard.

SWF assets in DHTML applications

DHTML cannot display SWF assets. As a convenience, the server and compiler automatically search for a corresponding png file if a SWF file is referenced in the DHTML runtime. To use this mechanism in your own code, create a png file with the same basename as the SWF file, and place it in the same directory as the SWF resource you want it to replace.

<resource file="resources/foo.swf" />

When compiled into a SWF runtime, this will still load resources/foo.swf as expected. When compiled into a DHTML runtime, this will try to load resources/foo.png.

The OpenLaszlo distribution also makes use of png replacements for SWF's, generated by an offline, batch tool. If resources/foo.png is not present, the server will try to load resources/autoPng/foo.png. The autoPng-generating-tool used by the OpenLaszlo developers is not yet available for re-use.

Fonts

DHTML doesn't support embedding fonts; SWF does. If you try to embed a font and compile for DHTML, you'll get a compile warning, and the text will look ugly, or it won't appear at all.

Using compression to reduce size of DHTML downloads

SWF files are internally gzip-compressed, which results in smaller files, especially when those files consist primarily of script, as do most OpenLaszlo-compiled applications. As a result, the smallest SWF-compiled OpenLaszlo application, which includes the LFC, is approximately 60K in size. The comparable DHTML-complied OpenLaszlo application, in contrast, is approximately 250K. This would be a serious problem, except that gzip compression is supported as part of the HTTP standard, and can be enabled in various ways, including by settings on the Web server (Apache Web Server or similar) or, when the deployment includes the OpenLaszlo server, in the Java server environment.

The effect of this compression, when correctly enabled in the serving environment, is that the compression is actually slightly better than the internal gzip compression supported by the SWF file format. Our measurements indicate that the 250K compresses down to 50K.

See the Deployer's Guide for a discussion of server-side and client-side compression.

SWF Assets in DHTML

SWF assets won't work in DHTML. To display a SWF asset, you'd need the Flash player; we're not using the Flash player in DHTML, so, SWF assets just won't appear. If you have an application that uses SWF assets and you would like to compile it for DHTML, the solution is to use bitmap assets instead of SWF's. The straightforward but painful way to do this is to convert your SWF assets to bitmaps. The clever way to do this is to take advantage of the "autoPng" feature; see New Features, above. (link)

DHTML-specific limitations requiring source-level lzx changes:

Due to the limitations of browser relative to the Flash runime, certain things are just not available in DHTML, or in all browsers. They are summarized below.

Opacity

You can't set the opacity of a view that contains text - but you can set a subview's opacity (IE only)

Safari popup-blocker workaround

In Safari 2.0.4 DHTML, the popup blocker will prevent windows from opening if not called directly from an onclick event. The workaround is to change the LZX source so the window is opened directly from the onclick event handler - see http://www.openlaszlo.org/jira/browse/LPP-3333?page=all.

Stretches

Stretches only works on leaf views with resources.

Keyboard events

Keyboard events: in DHTML, control, shift and alt are treated as 'modifier' keys. As a result, they are only sent when another key is pressed or a mouse event occurs.

For debugging the DHTML runtime, we recommend the FireBug extension to FireFox. If Firebug reports an error (with a little tiny red X in the bottom right hand corner of your firefox window) then there is probably a bug in your code or an OpenLaszlo bug. The errors reported by FireBug can be very obscure, but they usually happen when you are dereferencing a null pointer.

Deprecated and Removed

Discontinued demo

The "Dashboard" demo has removed from this release.

Limitations in This Release

Performance

Performance is slower than 3.4.x and it will be improved. The SWF runtime for OL4 is somewhat slower than the SWF runtime for OL3.4. The DHTML runtime for OL4 may be slower or faster than the SWF runtime for OL4, depending on the browser and on the specific actions being profiled. In some cases DHTML is definitely faster, for example, image loading is visibly faster in DHTML than in SWF. IE6 in particular is the slowest of the supported environments.

SOLO in DHTML requires Java 1.5

The DHTML SOLO tools do not to work with JDK 1.4; use JDK 1.5 instead.

Incubator

The Rich Text Editor, a SWF extension, has not been tested for SWF, and needs a rewrite for DHTML.

Components

• LPP-3690 The <html> tag is not properly supported in Firefox 1.5. This causes HTML content embedded using the <html> tag to fail to be displayed in Firefox 1.5.
• LPP-3539 Using <modaldialog> directly causes a Laszlo application to hang in IE 6/7 under dhtml. Here is an example that does not work properly in IE6/dhtml or IE7/dhtml:

          <canvas>
            <button onclick="md.open();">Show Modal Dialog</button>
            <modaldialog id="md" width="200" height="100" title="Modal Dialog">
              <button onclick="parent.close()">OK</button>
            </modaldialog>
          </canvas>
          

  The workaround is to create your own class that derives from <modaldialog>. The above code can be rewritten as:

          <canvas>
            <class name="safemodaldialog" extends="modaldialog"/>
            <button onclick="md.open();">Show Modal Dialog</button>
            <safemodaldialog id="md" width="200" height="100" title="Modal Dialog">
              <button onclick="parent.close()">OK</button>
            </safemodaldialog>
          </canvas>
          

  The only change is creating a class <safemodaldialog> that derives from <modaldialog>, and changing any references from <modaldialog> to <safemodaldialog>. This second example works in all supported browsers in dhtml and swf.

Laszlo Foundation Classes

• LPP-3194 History mechanism is not implemented in DHTML
• LPP-3515 Scroll wheel is not currently supported in the DHTML runtime.
• LPP-1948 text, inputtext and gridtext fields truncate strings at the introduction of "<"
• LPP-3703 In Internet Explorer 7 movement of a view positioned outside the canvas will refocus the iframe in which the application is embedded. Setting clip="true" on any surrounding view into which the outer view is moving corrects the behavior. See bug LPP-3682 for additional information.
• LPP-3436 LzCommand is not implemented in DHTML in this release.
• LPP-317 2 parts Irish Whiskey, 4 parts hot coffee, 1 tsp brown sugar, 1 1/2 parts double cream whipped until it begins to stiffen, floated on top
• LPP-2924 Full CSS support has not been integrated into the DHTML runtime.
• LPP-3433 Accessibility compatibility has not been fully tested.
• LPP-3587 Inspecting the height attribute of inputtext my provide erroneous results. Also Internet explorer evaluates inputtext.height differently from inputtext.getAttribute("height")
• LPP-2958 There are minor display differences between SWF and DHTML, because SWF uses a separate background movieclip, whereas DHTML just uses bgcolor attribute of text. Workaround (except Safari) is to put an extra view in behind the text view.

Extensions

• LPP-3691 issues with inputtext in ie6/7 in html example

Network Protocols

• The RPC-style network protocols XML-RPC and Java-RPC are supported in DHTML and SWF. The SOAP protocol is not available for DHTML in this release, but we expect to address that shortcoming in a subsequent update.
• LPP-3657 Implement SOAP RPC in DHTML
• The Persistent Connection manager does not work in DHTML. In Flash, it is a provisional feature with limited support.
• LPP-3657 SOAP server proxy does not currently have the capability to deliver JSON to a DHTML runtime client application.

Samples and Examples

• LPP-3719 Wrapped text may display orphan lines
• LPP-3716 Additional whitespace around some demonstration applications is visible. This symptom is due to the invoking link.
• LPP-2939 Make Amazon-SOAP work in Legals

Server

• LPP-3457 Do not deploy to WebLogic with the OpenLaszlo war file. The OpenLaszlo Compiler requires an expanded web application directory for logging and the creation of cache files. Make sure you deploy with the expanded web application directory instead of pointing to a .war file.
• LPP-2207 Setup SOLO Application Deployment" and "Preview SOLO Application in Browser" exhibit some minor cosmetic defects.

Kernel - DHTML

• LPP-3313 Animation playback is inconsistent between SWF and DHTML. Multi-frame resource animations in DHTML don't start automatically.
• LPP-3475 Resizing of InputText is not currently supported in the DHTML runtime.
• LPP-3642 Data loading is not compatible with Mobile Webkit. This bug is blocking basic compatibility between OpenLaszlo 4 and the version of WebKit shipped with Symbian Series 60 Release 3 Feature Pack 2.
• LPP-3716 LZPIX window is too big, white border around outside
• LPP-3703 IE issue with DHTML embed frame scrolling on unclipped views
• LPP-3539 dhtml: IE6/IE7: <modaldialog> locks up app
• LPP-2814 animations don't load in image-loading example, in dhtml
• LPP-3735 <html> embedding tag not working in FF2.0 / OS X in swf
• LPP-3194 Add history to dhtml browser integration

Resource Events in DHTML Kernel

There are several ways of resolving resource paths for multi-frame resources. They correspond to the following path examples:

1. <view id="v1" resource="http://www.openlaszlo.org/images/horses/horse-6-sm.jpg" />
2. <view id="v2" resource="http://www.openlaszlo.org/images/horses/animations/horse-anm-3.swf"/>
3. <view id="v3" resource="http://www.openlaszlo.org/images/animations/horse-anm-2s/" />
4. <view id="v4" resource="http://www.openlaszlo.org/images/animations/horse-anm-2s" />
5. <view id="v5" resource="images/horse-3-sm.jpg" />
6. <view id="v6" resource="images/animations/horse-anm-1L.swf" />
7. <view id="v7" resource="images/animations/horse-anm-2s/" />
8. <view id="v8" resource="images/animations/horse-anm-2s" />

Background: In the case of URL's (1, 2, 3, and 4) the resources are loaded at runtime through HTTP. In the case of local file references (5, 6, 7, 8) the resources are compiled as part of the LZX application.

1 and 5 work in DHTML and Flash as expected.

In general since SWF movie resources are not directly supported in DHTML, we have a couple of alternatives for interpreting 6 in DHTML. First the loader will look for png files in an immediate subdirectory of the given directory: i.e. in the case of "images/animations/horse-anm-1L.swf" it will look for "images/animations/horse-anm-1L/horse-anm-1L*.png". Then, if no png's are found there, it would look in the autoPng directory "images/animations/autoPng/horse-anm-1L*.png".

However, 2 will simply not work in DHTML at this point because we don't have a way of doing a directory listing over HTTP, although in an upcoming release it will behave the same as 6.

3 and 4 will also not work in either DHTML or Flash at this point, for the same reason.

7 and 8, however, will work as expected in both DHTML and Flash.

The following events are intended to be defined for views in both DHTML and SWF:

Multi-frame resource events

onframe, onimload, onlastframe, onplay, onstop, onopacity, onaddsubresource, onerror, ontimeout

Mouse Events

onclick, ondblclick, ondrag, onmousedown, onmousedragin, onmousedragout, onmouseout, onmouseover, onmouseup, onmouseupoutside

For the moment, many of the Multi-Frame Resource Events in DHTML are not fully tested. Those which are tested are listed below. nyt means not yet tested.

This testing was performed only on Firefox 2.0.0.2 on OS X 10.4.8.

* onlastframe can be fooled by setting a swf animation to self-terminate (from script inside the flash movie) before the last frame. onlastframe only knows about the frame count.

* MFD = multi-frame directory (a directory of png files resulting in a multi-frame resource).

Build System

• LPP-3465 lztest fails, but build returns success
• LPP-3720 Refguide is being built twice on build machines