• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OpenLaszlo applications life cycle

 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi.
What are the stages of developing OpenLaszlo applications?
Do we right tests (unit tests, integeration tests ..)? you know the usual paradigm.
What is the final output of an OpenLaszlo application?
(I mean we got JavaScript files from GWT applications, class files for Java source code for example).
When I have ready to work OpenLaszlo application, where to deploy it? in a web container?
Does an OpenLaszlo application need a runtime environment to be installed in the web container?
Thanks.
 
author
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I have ready to work OpenLaszlo application, where to deploy it? in a web container?
Does an OpenLaszlo application need a runtime environment to be installed in the web container?


The OpenLaszlo server is implemented as a Java servlet that resides within a web container (Tomcat) and contains a compiler for it's LZX language. Since its a serlvet, each release of OpenLaszlo is contained within a WAR file that can easily be deployed within the web container. Afterwards, its best to think of OpenLaszlo as an integral part of the web container, since it can't be directly called. A lzx file that resides within the OpenLaszlo directory, say lps-4.0.7, can be invoked to be compiled into either a deployable SWF or js file. Afterwards the facilities of the web container are used to deliver this executable. Since OpenLaszlo extends the existing facilities of the web container, by adding the ability to compile lzx source files into standard file formats, it can use all of the web container's existing services (SSL, cookies, ...)

Let's look at a simple example with a file called main.lzx. This file would be compiled just like a JSP file by invoking it through a URL like this:

http://localhost:8080/lps-4.0.7/my-app/main.lzx

This causes OpenLaszlo's compiler to, by default, compile this LZX source into a Flash SWF executable. But instead of being compiled into a servlet like a JSP file, it is compiled into a SWF file that is placed into a cache for delivery by the web container. It resides there until the LZX file is updated.

What are the stages of developing OpenLaszlo applications?
Do we right tests (unit tests, integeration tests ..)? you know the usual paradigm.


Developing an OpenLaszlo application is just like working in any other programming language. Since it consists of simple text files, there is no need for any fancy programming tools. OpenLaszlo supports all of the standard unit tests. So its development paradigm is almost identical to developing any other web application.

What is the final output of an OpenLaszlo application?

Since a SWF executable is a standalone executable, its proxied setting can be turned off to produce an application snapshot that is contained within a main.lzx.swf file (with LPS-4.X, it is called main.lzx.swf=lzr=swf7.swf). This proxied setting can either be set within the LZX application or within the URL like this:

http://localhost:8080/lps-4.0.7/my-app/main.lzx?proxied=false

After this URL has been invoked, this SWF executable will reside in the current directory. This is a new concept that's different from existing web applications, because the application is now separate from the original server and can be freely transported. So it can be served from an Apache or IIS server or just opened as a file. This also allows it to be embedded within HTML.

So far, I have only been discussing SWF executables, but everything also applies to DHTML executables. The execution type is set through the lzr parameter that we earlier saw.

http://localhost:8080/lps-4.0.7/my-app/main.lzx?lzr=dhtml

This setting causes the OpenLaszlo compiler to create the different executables from a single set of LZX source code. Of course, there are some restrictions or differences between Flash and DTML, for instance DHML can't handled embedded fonts, so your source code would contain a switch statement to isolate these areas:

<switch>
<when runtime="dhtml">
...
</when>
<otherwise>
..
</otherwise>
</switch>
reply
    Bookmark Topic Watch Topic
  • New Topic