OpenLaszlo 3.3.3 is a point release that addresses two regressions: media loading and in the use of the lzc script compiler. In addition, OpenLaszlo 3.3.3 helps prevent a potential security issue. OpenLaszlo 3.3.3 is the next qualified point release after OpenLaszlo 3.3.1, as OpenLaszlo 3.3.2 was an internal release.
For every release, we rely on the OpenLaszlo community to help ensure the quality of the platform release and to determine its future direction. We encourage you to report any problems, and to make suggestions for enhancements, through our JIRA bug tracking system.
Here is a summary of what you will find in these notes:
There have been two major bugs fixed since the OpenLaszlo 3.3.1 release: a problme that occurs when trying to run the lzc compiler and a media loading regression. Consult JIRA for complete information.
OpenLaszlo 3.3.3 addresses the following issues:
lzc.bat file and the lzc script compiler were not running correctly in the standard Windows XP configuration. This is because the OpenLaszlo installer places the files in "OpenLaszlo Server 3.3" directory inside the "Program Files" directory and the spaces in the names cause a problem. This problem has been corrected.lzc should be run from the /WEB-INF/lps/server/bin/lzc directory. The correct directory to run lzc from is:/Program Files/OpenLaszlo Server 3.3.3/bin/lzc
We strongly recommend that you follow the deployment recommendations in the System Administrator's Guide to Deploying OpenLaszlo Applications. In previous 3.x versions of OpenLaszlo, if you deployed a developer's kit, instead of making a deployment package, there was the potential that the the .jsp files used by OpenLaszlo Explorer could also be compromised to access files on your server. This represented a potential security risk.
In OpenLaszlo 3.3.3, the jsp files that enable OpenLaszlo Explorer remote compilation and source code viewing now prevent any access outside of the servlet working directory.
For the most current and complete information, consult the JIRA bug database.
There are two particular problems that we would like to call to your attention:
There is a common "UI" design pattern that is easily implemented within OpenLaszlo. This implementation, however, reveals a bug that some developers have encountered. In this particular UI design, a view is expanded in some dimension on rollover of the mouse and contracted upon mouseout. The code is often written like the following:
<canvas>
<view width="100" height="100" bgcolor="blue"
onmouseover="this.expand.doStart()"
onmouseout="this.contract.doStart()" >
<animator name="expand" attribute="width" to="150" duration="500" />
<animator name="contract" attribute="width" to="100" duration="500" />
</view>
</canvas>
The visual effect of the above code will fail, however, if the mouse is moved so fast by the user that the 2nd mouseover event occurs before the first expand animation is complete.
In other words, calling doStart() on an animator that is already running does nothing. It seems that the view has missed the 2nd mouseover event, when in actuality it is the animator that ignored its doStart() method call because it was already running.
For now, the work around is to use the javascript interface for animators like the following.
<canvas>
<view width="100" height="100" bgcolor="red"
onmouseover=" this.animate('width',150,500) "
onmouseout=" this.animate('width',100,500) " />
</canvas>
In this case, new animators are created with each new mouse event. These animators will run independently and will not have the same problems associated with them like those encountered with the animator tags. Run the examples above, and move the mouse quickly in and out of both views. Notice how in the second example the motion of the red box seems more natural.
Users have reported problems with applications embedded in some versions of Internet Explorer -- the applications don't appear. If you can't get your OpenLaszlo application to show up in IE, try using the older version of embed.js from 3.0.2. We couldn't fix it because we couldn't reproduce the problem, but using older versions of the embed.js sometimes made the problem go away.