Release Notes for LPS 3.0

OpenLaszlo release 3.0 marks a major milestone both in terms of the capabilities of the platform and also of the Laszlo open source process. This release has been qualified against the testing suite and is believed to be stable.

These release notes summarize platform changes since Laszlo Presentation Server release 2.2:

Key New Features

LPS 3.0 introduces several new features:

Most of the new features are described in the product documentation. For others (timeouts, fonts) these notes constitute the primary documentation.

SOLO Deployment

Laszlo applications can be made available on the web, or deployed in either of two ways:

  1. Deploy SOLO (Standalone OpenLaszlo Output) from any HTTP Web server
  2. Deploy with OpenLaszlo Server

With SOLO deployment, the LZX source is pre-compiled into a stand-alone SWF file that can be placed within the HTML docs directory of a common HTTP Web Server (such as Apache or IIS). SOLO deployments are simple to manage, and supported by nearly any Web hosting service.

With SOLO deployment, the OpenLaszlo Server is not required for operation of the application (although the Server is required for developing the application).

With OpenLaszlo Server deployment, the LZX source is placed within the Web-apps directory of the OpenLaszlo Server, and is dynamically compiled. OpenLaszlo Server deployment requires a Java Application Server or servlet container. It provides additional capabilities dependent on the server, including support for SOAP, XML-RPC, Java-RPC and persistent connections. The OpenLaszlo Server is also required for applications that use some media formats that are not natively supported by the Flash player. The OpenLaszlo sever transcodes these media files "on the fly" into formats supported by the Flash player.

See the "Proxied and Solo Applications" chapter of the Developer's Guide for more information.

Internal compression

The compiler now employs internal gzip compression. This results in substantially smaller object file sizes.

Dynamic Libraries

A dynamic library is a portion of a program that can be loaded after the main application execution file has loaded. The goal for dynamic libraries is to reduce the initial download size of a Laszlo application. This is important because initial download size (including all requests that precede initial user interaction) is used to evaluate web applications. Reducing the initial download size has the additional benefits of reducing the time to first interaction (although there are other ways of doing this), and of reducing bandwidth costs in the case where an optional feature of the application is not used.

See the Program Structure chapter of the Software Developer's Guide for details.

Unicode

Unicode fonts such as CJK fonts are now supported in <text> and <inputtext> fields. Unicode is supported:

The Laszlo components, such as <button>, do not work with unicode fonts. (They are fixed-height, and the default height is incorrect for most fonts.) Only the core classes, <text> and <inputtext>, are automatically sized for unicode fonts.

Encoding

By default, LZX now expects text to be UTF-8. You can specify a different encoding within an <?xml?> processing directive at the beginning of an application source file or an XML data file:

<?xml encoding="UTF-16"?>
<canvas>…</canvas>
<?xml encoding="ISO-8859-1"?>
<data>…</data>

Swf6 and Swf7 support

The compiler now outputs, and has been optimized for, swf6 and swf7 binaries. Swf6 is the default;the swf7 target is available as an option. Swf5 format is no longer supported.

Settable Timeouts

Settable Timeouts is a mechanism for setting the timeout of a request. There are global settings for data request and media request timeouts, and per-dataset requests.

API

New canvas attributes:

nametypedefaultdescription
dataloadtimeout number 30000 (30s) timeout time in milliseconds for data requests
medialoadtimeout number 30000 (30s) timeout time in milliseconds for media requests

dataloadtimeout is the defaults for newly created datasets. Changing it doesn't have an effect on dataasets that already exist.

New dataset attribute:

nametypedefaultdescription
dataloadtimeout number 30000 (30s) timeout time in milliseconds for this dataset

The timeout time can be changed at runtime, and that will affect any subsequent requests made on behalf of the dataset.

Drawing API

LZX now includes a subset of the WHAT-WG graphics API .

A new class DrawView extends LzView. See the LZX Reference Manual for description of this class.

Client fonts

A client font is a font that is located on the client machine. Text that uses client fonts is faster, and avoids the size penalty of an embedded font (a font that is compiled into the application). This is particularly important with CJK fonts, which are many megabytes.

Previous versions of OpenLaszlo could only use embedded fonts. This release can also use client fonts:

The value of the font attribute is the name of a font. This may be the name of an embedded font (one that has been declared with the <font> tag), or a client font (one that is available on the client operating system).

There are three always-defined client fonts, which can be accessed by special names. (These names will probably change prior to the final release.)

There are also two Japanese fonts, the equivalent of _sans and _serif, whose names can only be written in Unicode.

Resizable Canvas

The canvas width and height can be specified as a percentage (e.g. <canvas width="50%">). When the canvas dimension are a percentage value, the application is scaled according to the size of the HTML page. In this, onheight and onwidth events on the canvas are generated when embedding HTML page is resized.

Communication with browser JavaScript

A new service LzHistory(), and a new JavaScript function LzSetCanvasAttribute(), allow two-way communication between the a Laszlo application and the browser's Javascript engine.

You can access the javascript engine in the browser using the loadJS method on LzBrowser:

LzBrowser.loadJS(js, target)

argumentvalue
js JavaScript string to execute
target Optionally specifies a named frame in which to execute the JavaScript expression.

By default, the JavasSript expression specified in js is executed in the current browser frame.

See the Browser Integration chapter of the Software Developer's Guide for more information and examples.

Browser Back Button support

The LzHistory mechanism makes it possible for Laslzo applications to capture program states and move among them using the browswer's "back" button. See the "Browser Integration" chapter of the Developer's Guide for details.

Performance Improvements

Several architectural changes have been made to improve performance:

Register allocation
The compiler now uses registers. The user-visible effect of this is a significant speed-up in the generated code.
Clipped views are faster
Clipping uses swf6 primitives. The user-visible effect is better performance for clipped views.
Faster compiler
Assembler now implemented in Java rather than Python. The user-visible effect is that Laszlo apps compile faster.
Internal file compression
Application files are compressed internally, regardless of http encoding. This results in smaller transfer sizes on clients that don't accept the gzip encoding, as well as a smaller application size in the browser cache.
Client fonts
Text fields that use client fonts are significantly faster than those that use embedded fonts.
Inlined classes.
An inlined class is a class that is applied to an instance when an application is compiled, rather than when the application is instantiated. An inlined class has the same semantics as a regular class, except that the class cannot be instantiated or otherwise referred to by name in script code. An inlined class is similar to an inline function, or a macro, in other languages.

Text maxlength and restrictions

Text fields have new attributes

maxlength:  max number of chars you can add to an text field
pattern:  whitelist or blacklist of chars that can be added to a text field

which follow the same semantics as the Flash TextField object fields of the same names

Debugging improvements

Inspecting objects is more robust and readable. The size of a string or array is now included as part of its type. This can be useful when deciding whether to inspect a string or array that has been abbreviated (i.e., if you inspect a gigantic string, the debugger will print the full string, which may take a long time.)

ECMAScript changes

When it can, the compiler will warn about mis-matched case for JavaScript tokens. This is in anticipation of full ECMAScript compatibility which enforces case-sensitivity.

Support for ("right click") context menu

The right click "context" menu is now supported. Documentation forthcoming in the next release. Here is a sample program that demonstrates the API:

<canvas debug="true" width="1800" height="800">
  <method event="oninit">
    Debug.showInternalProperties = true;
  </method>

  <debug x="200" fontsize="14" width="600" height="400"/>
<script>

function rightclick_handler (obj, menuobj) {
  Debug.write("rightclick context menu", obj, menuobj);
} 

function my_itemhandler(obj, item) {
   Debug.write("menu item selected", obj, item);
}

var cm1 = new ContextMenu(rightclick_handler);
cm1.hideBuiltInItems();
cm1.addItem(new ContextMenuItem("LZX Canvas Custom Item!", my_itemhandler));
canvas.setContextMenu(cm1);

var cm2 = new ContextMenu(rightclick_handler);
cm2.hideBuiltInItems();
cm2.addItem(new ContextMenuItem("View Custom Item 1", my_itemhandler));
cm2.addItem(new ContextMenuItem("View Custom Item 2", my_itemhandler));
cm2.addItem(new ContextMenuItem("View Custom Item 3", my_itemhandler));


var cm3 = new ContextMenu(rightclick_handler);
cm3.hideBuiltInItems();
cm3.addItem(new ContextMenuItem("Text Custom Item 1", my_itemhandler));
cm3.addItem(new ContextMenuItem("Text Custom Item 2", my_itemhandler));

</script>
<simplelayout/>
<text id="foo"  fontsize="26"
      oninit="setContextMenu(cm3)">FOOBAR</text>
<view id="pp"  
      width="200" height="200" bgcolor="blue" 
      oninit="setContextMenu(cm2)"/>
</canvas> 

Mouse wheel Support

OL 3.0 has an event called LzKeys.onmousewheeldelta. See the Reference Manual.

Documentation restructuring

The Developer's Guide ("Guide to Designing, Developing and Deploying Laszlo Applications") has been trifurcated into Developer's, Designer's and Deployer's Guides in order to tailor information to different audiences.

Name Change: Goodbye "Laszlo Presentation Server", hello "OpenLaszlo Server"

With this release the Laszlo Presentation Server ("LPS") has been renamed the OpenLaszlo Server. Accordingly the "Start Laszlo Presentation Server" menu item and alias has been renamed to "Start OpenLaszlo Server", and similarly for "Stop". The Laszlo Explorer and documentation have been edited to reflect this change, although their are many places where the old nomenclature persists. Over time the documentation and user-visible artifacts will be transitioned to OpenLaszlo, although in the code the LPS terminology is likely to persist indefinitely (for example, in directory names).

Significant Bug Fixes since LPS 2.2

Since 2.2 many bugs have been remedied. Among the more significant:

See below for a cumulative list.

Backwards-incompatible Changes in 3.0

New functionality in OpenLaszlo 3.0 has necessitated a few backwards-incompatible changes from prior releases.