As we said above, web browsers display HTML pages. This means that OpenLaszlo applications are delivered to browsers by means of HTML pages. Sometimes those HTML pages contain nothing visible to the user other than the LZX application itself. In such cases the HTML page is essentially invisible, and the fact that there's an HTML page there at all doesn't really matter to the developer or to the user of the application. Such HTML pages, whose only function is to present the OpenLaszlo application to the browser, are sometimes called "wrapper pages."

Depending on which target runtime they're compiled for, OpenLaszlo applications have different relationships with the JavaScript engine of the browser in which they run. To a rough approximation, LZX applications compiled to SWF are foreign objects embedded into an HTML page, and you must use a formal protocol to get across this logical barrier between the LZX application and the JavaScript engine. Applications compiled to DHTML become just a part of the HTML page that contains them. From the point of view of the browser, there is no difference between the OpenLaszlo application and the surrounding page.

But although some of the implementation details differ for the different runtime targets, the OpenLaszlo APIs are, wherever possible, consistent, so that you use the same programming model regardless of the target runtime. So, for example, there is a method called swfEmbed()for embedding SWF OL applcations into the HTML page; this generates an HTML <embed> tag. Similarly, there is an dhtmlEmbed() for placing an OL application compiled to DHTML within a web page. In this case there is no <embed> generated or required, but the methods have similar names because they perform analogous functions.

Applications compiled to SWF are executed by the Flash player and must make use of the LzBrowser service in order to "escape" to the browser's JavaScript environment.

Any attributes that are declared on the canvas are visible to the browser JavaScript. To go "the other way", from the browser "into" the OpenLaszlo application, the setCanvasAttribute() and setCanvasAttribute() methods are used.

This are discussed below.

Alhough OpenLaszlo applications deployed on the Flash runtime are not dependent on the browser or operating system for their look or behavior, there are some important limitations that the browser container places on the application. There are also a number of Flash Player features that your application can use which are not available in applications compiled to DHTML.

OpenLaszlo applications compiled to SWF can be sent from the OpenLaszlo Server to client in any of several forms:

2.2.1. The LzBrowser service

SWF only: The features described in this section only work in applications compiled to SWF. They do not work in applications compiled to other runtimes.

The LzBrowser service provides access to the browser and player environment. It includes methods to load URLs in the browser and check the version of the player. Furthermore, by using the LzBrowser service together with other OpenLaszlo functions described below, you can build applications that pass information and control between the OpenLaszlo application and the JavaScript of the browser.

The LzBrowser is always running.

DHTML only: The features described in this section only work in applications compiled to DHTML. They do not work in applications compiled to other runtimes.

Applications that are compiled for DHTML run within the browser's JavaScript envinronment. They are essentially compiled into the DOM of that page.

Each LZX application has exactly one <canvas> element, which, when compiled to DHTML, becomes an object. When you embed an LZX application compiled to DHTML into an HTML page, it just becomes part of that page's DOM,and you can address it directly. The "foo" object of the LZX application becomes canvas.foo of the DOM. If there is a swf embedded in that (DHTML) Openlaszlo application, you can still use the mechanism for talking to SWF applications to reach it.

For DHTML, you can call canvas JavaScript directly because it is loaded in the browser. That is to say, unlike in the case of communicating with SWFs, you do not need to use setCanvasAttribute() ore setCanvasAttribute(), nor do you need to use the LzBrowser service.

2.3.1. Embedding the LFC for DHTML applications

DHTML only: The features described in this section only work in applications compiled to DHTML. They do not work in applications compiled to other runtimes.

When you compile an application to SWF, the compiler includes the Laszlo Foundation Class, or LFC in the resulting file. This does not happen for applications compiled to DHTML, therefore the LFC must be downloaded explicitly. To make the LFC available to DHTML applications, include the following call in the page head:

The optional appenddivid property can be passed in to swfEmbed() or dhtmlEmbed() method to specify the id of a div whose contents should be replaced with the LZX application. If a div with that ID doesn't exist, one will be written into the document where swf/dhtmlEmbed() is called. If appenddivid is not specified, the div written will be based on the id property + 'Container'.

Alternatively, you can generate wrappers by using the various request types on the url you use to browse to your application, as explained in Chapter 48, Understanding Compilation:

The default wrapper page contains logic to detect the version of flash running on the client.

This page that will look something like the following:

Depending on which version is running, you may wish to use some LZX features that run in some, but not all, versions of the Flash Player.

When laying out a page that will use OpenLaszlo applications in different places, you can use a frameset like this:

<html>
<frameset cols="128,*">
  <frame name="navBar" src="myOpenLaszloNav.lzx?lzt=html" />
  <frame name="contentArea" src="myOpenLaszloContent.lzx?lzt=html" />
</frameset>
</html>

Inside your application use the target parameter of LzBrowser.LoadURL() to load pages in the target frame.

LzBrowser.loadURL('http://www.laszlosystems.com','contentArea');

Like framesets, OpenLaszlo applications can be embedded within an "inline frame" or <iframe> which can be more flexible for your layout and easier to use. Like regular frames, inline frames can be named for later reference by the OpenLaszlo application.

<html>
  <body>
    <h1>Here is a header</h1>
    <div align="center">
      <iframe src="myOpenLaszloApplication.lzx?lzt=html" width="200" height="200" 
              frameborder="0" name="inlineApplication" scrolling="no"/>
    </div>
  </body>
</html>

Bear in mind that the iframe will contain a canvas, and unless you want the browser to provide scrollbars, you should set the width and height equal to that of your canvas plus any margin you may have included.

The same way you would target content to a frame, you can target the loadUrl to new window.

Example 35.8. new Blank window

<canvas height="27" >
  <button onclick="LzBrowser.loadURL('http://www.laszlosystems.com','_blank');" text="Click Me!"/>
</canvas>

This mechanism can also be used to name the window allowing subsequent loads to occur in the same window

Example 35.9. new Blank window

<canvas height="56" >
  <simplelayout/>
  <button onclick="LzBrowser.loadURL('http://www.openlaszlo.org','newOpenLaszloWindow');" text="OpenLaszlo Homepage"/>
  <button onclick="LzBrowser.loadURL('http://www.mylaszlo.com','newOpenLaszloWindow');" text="myLaszlo.com"/>
</canvas>

Once the data has been passed in you can simply access it as a global variable from within the OpenLaszlo application.

<canvas debug="true" oninit="Debug.write(globalVar)"/>       

In many cases you will have full control of the HTML content that is embedding your application. In many other cases you won't be able to depend on the existence of those query parameters so it is wise to provide sane defaults for those values:

Example 35.12. Setting defaults

<canvas debug="true" width="200" height="200">
  <script>
    var innerVar = typeof(global.globalVar) != 'undefined' ? global.globalVar : 'bar';
    Debug.write(global.innerVar);
  </script>
</canvas>

The above application is requested without a globalVar query parameter. The debugger therefore displays the default value bar. If this application is requested with the globalVar=foo query parameter, it will display the default value 'bar'. Click here to see the application in a popup window with the query parameter applied.

Using query parameters, you can craft your application to start up in a specific state. The default behavior of a tabslider is to have none of the tabelements opened at startup. The following application changes that default to open to the tab specified on the query parameter, and if one isn't provided, open to the first element.

Example 35.13. Restoring state

<canvas width="300" height="250">
  <script>
    var opened = typeof(global.tab) != 'undefined' ? global.tab : 'one';
  </script>
  <tabslider width="150" x="10" y="10"
             height="200"
             spacing="2" slideduration="300" oninit="this[global.opened].setAttribute('selected',true)">
    <tabelement name="one" text="Tabelement One"/>
    <tabelement name="two" text="Tabelement Two"/>
    <tabelement name="three" text="Tabelement Three"/>
  </tabslider>
</canvas>

Click here to see this application in a popup with a different initial state applied. This is useful when creating links from outside the application, or for creating a bookmark for an application. Another thing to do is read browser cookies from JavaScript and pass in the parameters when calling the application.