Runtime Differences
From OpenLaszlo
This is a starter page to collect user-visible differences in how the LZX applications behave in the various runtime targets. In addition, it provides information about any changes required to run your application in OpenLaszlo 4.1, which is the release supporting DHTML. Further updates coming.
Upgrading to OpenLaszlo 4.1 SWF/DHTML Release
User classes can no longer be defined in the global namespace
Anyplace your code says:
<class name="foo" .../> new foo(...)
will have to be changed to:
new lz.foo(...)
Also, any references to "ConstructorMap" must be changed to "lz"
This is part of our campaign to reduce global namespace pollution so we interact better with other frameworks. It also prevents component names from conflicting with built-in browser objects, e.g. window.
Sebastian Wagner has posted an eclipse plugin to help with this issue - see http://code.google.com/p/laszlo4converter/
You can also use this perl script, if you prefer, to automatically update dynamic instantiations user of user classes.
Image:Convert instantiation.pl
Warnings may appear for deprecated language features
OpenLaszlo 4.1 warns you about deprecated syntax in use in your application. We have provided a simple perl conversion script (convert_laszlo.pl)to help eliminate the majority of these warnings. This requires Perl 5 or greater.
NOTE: use this in small increments and review the changes to avoid unanticipated side effects. You can view the perl script, even without an OpenLaszlo installation, here: http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/server/bin/convert_laszlo.pl
To run the script, type:
perl /path_to_script/convert_laszlo.pl where path_to_script is the path to your OpenLaszlo installation
Usage:
perl convert_laszlo.pl [ options ] filename...
Options:
-d debuglevel get debugging info for development
-t create output for simple tests in /tmp/convtest
-x exceptlist exceptlist is a comma separated list of transforms
to NOT apply. These are chosen from:
method - <method ...> transforms
setattribute - setVisible -> setAttribute('visible', ...) etc.
widthheight - getWidth(),getHeight() to width,height
tagname - constructor.classname to constructor.tagname
states - apply=" -> applied=", state.apply()/remove() -> setAttribute('applied', true|false)
-v show version number and exit
For each file, a backup file is made (filename.bak) and the file will be converted, with the result put into filename.
Examples:
# Convert all the lzx files in the directory, doing all conversions. perl convert_laszlo.pl *.lzx # Convert just myfile.lzx, do not apply two of the conversions. perl convert_laszlo.pl -x setattribute,tagname myfile.lzx
HTML embedding APIs changed
Lz.swfEmbed is now lz.swf.embed(), Lz.dhtmlEmbed() is now lz.dhtml.embed(), and Lz.dhtmlEmbedLFC() is now lz.embed.lfc(). For the most up-to-date information on embedding, click the 'Deploy: [Server]' button on the developer's console for any application, e.g. http://labs.openlaszlo.org/trunk-nightly/my-apps/copy-of-hello.lzx?lzr=swf8&lzt=deployment
WEB-INF/web.xml has changed
A number of changes were made to the default WEB-INF/web.xml in LPS 4.1. If you have a custom web.xml for your application, you may need to merge it with the version web.xml for LPS 4.1 - see http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/web.xml for a current version.
Names, IDs and method arguments must use valid JS2 names
You may receive compiler errors if you use reserved words such as "private" "public" or "is". JS2 names can contain letters, numbers and underscores but must nut begin with a number.
Methods called by delegates/events must have a single argument
Where a delegate calls a method, you will see warnings if the method had no arguments. Adding an argument to these methods e.g. <method args="ignore"> will silence the warnings and get your code ready for the upcoming Flash 9 release.
<method event="eventname"> is deprecated
The syntax <method event="eventname"> is now deprecated and will trigger a compiler warning. You should update your code to use <handler name="eventname">. In the case where the method is named (<method event="eventname" name="methodname">) you will have to split the declaration into a handler (<handler name="eventname" method="methodname" />) and a method (<method name="methodname">).
This syntax allows subclasses to override the method that will be handling the event. See the documentation (http://www.openlaszlo.org/documentation) of handler for further details and examples.
Duplicate attributes now cause compiler warnings
In previous versions of LZX, you could potentially create a duplicate attribute with no warning from the compiler. For example:
<class name="zot">
<attribute name="name" value="${'bar'}" />
</class>
In the above example, the attribute named `name` is defined both in the open tag of the class and as an attribute. This is illegal and could lead to ambiguous or unpredictable results. The compiler will now warn that you have a duplicated attribute. You will have to rename one of the duplicate cases to ensure that your code works as expected.
Other API changes
LzDataNode.stringToLzData() has been moved to to LzDataElement.stringToLzData()
<datasource> is no longer supported in 4.1
<script/> includes
<script/> includes may need the when="immediate" attribute added to ensure they are compiled early enough to be ready to use in the application. This generally only applies to classes.
States no longer support super() calls in methods
The workaround is to move the super() call to a method that's can be called from the state
Swf resources compiled for earlier versions of Flash don't support playback control in Flash 9
In Flash 9, properties and methods are not accessible in swf files compiled for previous versions of the player. This is a restriction in Flash 9 - see http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000011.html for more details.
DHTML limitations
Rotation
Rotation is currently only supported in recent builds of Safari.
Stretching nested subviews
Stretching only works for views that don't have subviews, or nested children.
<font/> includes
DHTML does not support font inclusion. If <font> tags are used, the compiler will give warnings for DHTML. Note that it is possible to specify a list of font names which will be used in the order available. This allows font includes to work in supported runtimes such as Flash, and fall back to a suitable system font in DHTML.
Persistent Connections
Persistent connections are not supported in DHTML and are deprecated in Flash.
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.
<splash/> tags
It's difficult to get meaningful load progress information in DHTML, so this feature was deprecated to provide a more consistent experience for developers and users. LPS 4.1 has a new mechanism - essentially, an event is now sent when the app finishes loading, and arbitrary javascript can execute. By default, the HTML for DHTML applications contains a div with a progress animation that is hidden when the application finishes loading. Run see any app with lzr=dhtml&lzt=html for an example. The <splash/> tag will continue to work in Flash as-is. The Reference Manual documentation for the <splash> tag has been updated with this information. Also see http://www.openlaszlo.org/jira/browse/lpp/LPP-5280 for more details.
XML data in SOLO apps
The Flash player is generally more lenient than browser JavaScript parsers.
For DHTML apps running in SOLO mode, the web browser's XML parser is very picky about the data source. The server delivering the data must mark the HTTP content type header as text/xml and it doesn't hurt to have an <?xml ... ?> declaration either, and no white space between the start of the file, the <?xml...?> declaration, and the start of the data.
Safari 2 and popup blockers
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.
Internet Explorer and opacity
Internet Explorer 6 and 7 have a number of limitations with the way they handle opacity. We've worked hard to work around these limitations where possible. Unfortunately, some limitations require minor changes to the structure of your LZX to work properly in IE:
- Can't set the opacity of a view that contains text - but can set a subview's opacity.
- Can't reliably set the opacity on child views if a parent view has opacity. Child views disappear or appear clipped instead of changing opacity. See http://www.openlaszlo.org/jira/browse/LPP-5370 and http://www.openlaszlo.org/jira/browse/LPP-5382 for examples and simple LZX-level workarounds.
