To return the "naked" OpenLaszlo application without the Developer's Console, simply compile the application using the "URL" method of placing the URL to the application in your browser's address bar with ?lzt=html appended to the address. This will return the application in an HTML page. See Chapter 48, Understanding Compilation and Chapter 35, Browser Integration for elaboration of this topic.

In order to run your program, simply load it into your browser. The exact URL depends on the configuration of the server, but will typically look something like:

http://127.0.0.1:8080/lps-4.0.3/path to your directory

The OpenLaszlo Server checks the source files for valid syntax, compiles them, caches the executables and makes the application immediately visible in the browser.

The standalone compiler is called lzc. Its location depends on how you have installed OpenLaszlo. Developers who build OpenLaszlo from the source will find lzc in $LPS_HOME/WEB-INF/lps/server/bin/. Developers who install OpenLaszlo with a binary installer will find it in the directory OpenLaszlo Server 3.x.x/bin.

Developers with more than one version of the OpenLaszlo server in play should define an alias: alias lzc='$LPS_HOME/WEB-INF/lps/server/bin/lzc'. By defining an alias based on $LPS_HOME, one can have multiple shells -- each with a different $LPS_HOME -- and the alias will map to the correct compiler for each shell

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.

If you open a local SWF file in Internet Explorer, or an HTML page that accesses a local SWF file in Internet Explorer, you will get a "blocked content" warning message. You can safely disregard this message and continue developing. Here is why: this is not a problem with OpenLaszlo nor is it a problem with IE per se. Rather it is a security feature built into IE to keep viruses from accessing ActiveX controls, and it only appears when you're developing applications, not when you're deploying them.

Internet Explorer uses an ActiveX control to display Fash files. It assumes that a local file trying to access an ActiveX control may very well be a virus, so it puts up the warning.

When you actually deploy your OpenLaszlo application, however, it will be served to your visitors through a Web Server (IIS, Apache, etc) off of an actual domain, and therefore will not show the error message. To verify this, run a web server locally on your system and serve the page off of your local web server. you will see that the error message will not be displayed.

Please see also the discussion of SWFObject in Chapter 35, Browser Integration for a more complete discussion of embedding Flash files in HTML pages.

Within LZX applications, you can embed arbitrary Javascript functions by nesting them in <script> constructs. This is helpful for defining (global) functions that will be used by different classes. The <script> tag must be a child of <canvas>. That is to say,

<canvas>
  <script>
    var Constant = 1;
  </script> 
</canvas>

is an allowed structure while

<canvas> 
  <view> 
    <script> 
      var Constant = 1;
    </script> 
  </view> 
</canvas>

Wrong! The <script> tag is not allowed inside a view!

is illegal.

In LZX the id attribute of an object is a global identifier that is visible throughout the entire program space, while the name of an object is an attribute like any other, which can only be referenced by its path (except in the case of named children of the canvas, as noted below). Consider

<canvas> 
  <view id="v1" name="outer_view"> 
    <view id="v2" name="inner_view" bgcolor="blue"/> 
  </view> 
</canvas>

The value of the outer view's background color can be referenced as v1.bgcolor or outer_view.bgcolor. The background color of the inner view can be referenced as v2.bgcolor from anywhere within the application. To reference it by name from outside of inner_view you would specify outer_view.inner_view.bgcolor.

Objects that are named children of the canvas can be simply addressed. For example, consider

<canvas>
  <view name="artichoke">
  <!-- more program code -->
</canvas>

The view artichoke can be referenced from anywhere within the application simply as artichoke. That is, it is not necessary to reference it as canvas.artichoke.

A view is only visible if it has color, or text, or an image assigned to it, and if the height and width of the view are greater than zero. For example, the following code would display only two images even though four views are defined. The second and third views exist but they are completely invisible. The second has no color assigned to it and the third has zero height. They still, however, affect the arrangement of the other two views.

Example 4.8. nested views

<canvas height="100"> 
  <!-- shows a red square: --> 
  <view width="50" height="50" bgcolor="red"/>
  <!-- nothing is displayed, but view still exists: --> 
  <view width="50" height="50"/>
  <!-- nothing is displayed, but view still exists: --> 
  <view width="0" height="50" bgcolor="blue"/>
  <simplelayout axis='x' spacing="5"/> 
</canvas> 

Views can also contain other views, allowing you to create complex visual elements. Each 'parent' view can have any number of children. By default, each child view is positioned relative to the top-left corner of its parent as shown in the example.

Although it is always possible to position any view by specifying its horizontal (x) and vertical (y) origin, stated in pixels, relative to its parent, it is often convenient to have the system lay things out for you. Layout types built into the system include <simplelayout> , <stableborderlayout> , <constantlayout> , <resizelayout> and <wrappinglayout> .

Consider the following application:

Example 4.9. Parent and children dimensions

<canvas height="200"> 
  <view bgcolor="red" x="50" y="50" width="100" height="100"> 
    <view bgcolor="yellow" x="50" y="50" width="60" height="105"/> 
  </view> 
</canvas> 

Running the example above also shows that the width and height of a view can be different than the dimensions of the bounding box of its child views. No clipping occurred on the "yellow" view even though it lies outside the boundary of its parent.

If no width and height are actually defined for a view, then it will adopt the width and height of the bounding box not its subviews. If clipping is desired, however, then the attribute clip="true" can be added to the parent, which would look like the following.

Example 4.10. clipping

<canvas height="200">
  <view bgcolor="red" x="50" y="50" width="100" height="100" clip="true"> 
    <view bgcolor="yellow" x="50" y="50" width="60" height="105"/> 
  </view> 
</canvas> 

In addition to showing text and color, views are used to display, or play, media files of various formats, such as .gif, .jpeg, .png, .swf, and .mp3, for example. These resources may be compiled into the application or brought in at run time; they can be on the OpenLaszlo server or on a remote back end, and can be referenced by relative paths or absolute ids.

This tag allows you to specify the name of a file to be include at any point in your application. The file to be included can be a library, a view, or text.

When the target is a library file (an XML file whose root element is <library> ), the contents of the library file are included in the application. Any views, scripts, fonts, resources, audios, datasources, datasets, class definitions, etc. in the library file are included in the application. A library file can include other libraries, but a library is included in an application only once, no matter how many <include> statements reference it. For example,

<canvas> 
  <include href="library.lzx"/> 
  <mywindow/> 
</canvas> 

<library> 
  <class name="mywindow" extends"window" 
         title="My Title"> 
    <button> Click me! </button> 
  </class> 
</library> 

The semantics for including views and text are analogous but slightly different. Unlike including a library file, a non text or view file is inserted once each time it's included.

These take the form

<!--  comment -->

and may appear between (but not within) tags in XML text. XML does not have a separate syntax for line ending comments, and does not allow nested comments.

Often when debugging you find yourself commenting out sections of code. Because it's illegal to nest XML comments within XML comments, this technique does not work for commented sections of declarative LZX. A good way around this problem is to use XML processing instructions which are of the form

<?ignore

?>

So, to comment out the blue and green views below,

Example 4.14. Commenting out code

<canvas height="100">
  <simplelayout/> 
  <!-- This is a red view --> 
  <view bgcolor="red" width="100" height="20"/> 
  <?ignore 
  <!-- This is a blue view --> 
  <view bgcolor="blue" width="100" height="20"/> 
  <!-- This is a green view --> 
  <view bgcolor="green" width="100" height="20"/> 
  ?>       
  <!-- This is a yellow view --> 
  <view bgcolor="yellow" width="100" height="20"/> 
</canvas>  

	Lines between <?ignore and ?> are ignored
	End of the ignore section

In script, block comments are of the form

/* comment */

Line ending comments start with // and continue to the end of the line:

// line comment

<script> 
  /* script comments look like this */ 
  some.method() // this is an example of comment syntax 
  <!-- ERROR!  do not enclose XML comments in script! --> 
</script>  // ERROR! Do not include script comments in XML!

The OpenLaszlo Server contains a code viewer that you can use to inspect any XML file in the lps directory, including, of course, .lzx sources. When used to read .lzx files, the viewer displays syntactically-colored sources, as well as a list of cross-references such as classes, libraries and art assets. To invoke the veiwer, in a browser window enter the URL to /lps-4.0.3/lps/utils/viewer/viewer.jsp and supply the name of the file you want to view as a file= request type, for example:

http://127.0.0.1:8080/lps-4.0.3/lps/utils/viewer/viewer.jsp?file=/my-apps/copy-of-hello.lzx