I've opened a discussion on the project forums about how to improve how we distribute information about the project and updating the project blog. If you read this blog (live or via RSS), your opinion is solicited on how I can make this better for you. Please visit:
http://forum.openlaszlo.org/showthread.php?t=11842
and see what is being considered, and let us know what you think.
If you're trying to get the most out of OpenLaszlo, consider taking one of our training classes on OpenLaszlo. We've just scheduled sessions here in San Mateo for both OpenLaszlo Fundamentals and our Building OpenLaszlo Applications classes. Sessions in Toronto and Hyderabad are also being scheduled.
More information on the classes is available here
We had a glitch with the downloads of 4.0.12 that had to be fixed. If you downloaded it before 11:30AM EDT on 4/15/2008, please redownload it at http://www.openlaszlo.org/download.
To make sure you have the proper release, check the build number in Laszlo Explorer. It should report r8678.
OpenLaszlo 4.0.12 is a is the latest version of OpenLaszlo and contains bug fixes, enhancements, and other changes from previous versions.
If you are using an earlier version, we recommending upgrading to 4.0.12, which is the recommended release for swf development. Support for applications to DHTML remains at "beta" level; it will be fully supported with OL 4.1.
To see the list of changes, please refer to the Release Notes
For every release, we rely on the OpenLaszlo community to help ensure the quality of the platform release and to determine its future direction. To propose or participate in discussion of new features, see the wiki. We encourage you to report any problems, and to make suggestions for enhancements, through our JIRA bug tracking system.
There is a new utility checked into trunk, which is a command line interface to build SOLO deployment zip archives.
You invoke it via the "lzdeploy" script, which is in
WEB-INF/lps/server/bin/lzdeploy
It take the following arguments, and produces an output file by default in the same directory as the app
resides. So for example if it is invoked on a relative path to an app in directory "test/foo/hello.lzx"
lzdeploy --runtime=dhtml test/foo/hello.lzx
it will produce a zip file, test/foo/hello.lzx.zip. This is basically the same routine that is run by the SOLO deploy 'wizard' jsp
script, but can be run from the command line, without needing to use the browser and LPS server.
You can get help with the --help argument:
badtzmaru:trunk3 hqm$ lzdeploy --help
Usage: lzdeploy [OPTION]... FILE...
Options:
-D<name>=<value>
Set the name/var property to value (See Compiler.getProperties).
-D<name>
Short for -Dname=true.
--wrapperonly
Only emit html wrapper page.
--runtime=[swf7|swf8|swf9|dhtml]
Compile to swf7, swf8, swf9, dhtml
--output pathname
The name of the output file to write.
--title titlestring
The title of the application to use in the wrapper.
-v
Write progress information to standard output.
--help
Prints this message.
OpenLaszlo 4.0.11 is a is the latest version of OpenLaszlo and contains bug fixes, enhancements, and other changes from previous versions.
If you are using an earlier version, we recommending upgrading to 4.0.11, which is the recommended release for swf development. Support for applications to DHTML remains at "beta" level; it will be fully supported with OL 4.1.
To see the list of changes, please refer to the Release Notes
For every release, we rely on the OpenLaszlo community to help ensure the quality of the platform release and to determine its future direction. To propose or participate in discussion of new features, see the wiki. We encourage you to report any problems, and to make suggestions for enhancements, through our JIRA bug tracking system.
Work is underway to to extend the compiler to know how to emit a singleton classes for views which declare methods or constraints. This is needed to support the unique feature of the LZX language which allows you to program an instance as if it were a full-fledged class.
There is also a simple debugger area, where you can type arbitrary javascript expressions, which are compiled at the LPS server and executed interactively, in a similar manner to the SWF8 debugger. The port of the full SWF8 debugger is planned.
Work remaining to be done includes porting the LFC data-handler classes, and supporting the media playback APIs in the swf9 LFC kernel.
