Don Park recently spent some time with the Laszlo Presentation Server and drew a nice architecture diagram in his blog. Generating an LZX from a JSP is one way to create applications in Laszlo. A more common development pattern is to simply write an LZX file that references an XML data source. I’ve drawn a diagram with a similar structure to Don’s that shows the HTTP requests from the browser, to illustrate how this works.
1. The user goes to the web page “http://mysite.com/hello.html”
(a) the browser requests “hello.html” from mysite.com
(b)The web server sends that document it to the browser.
2. The browser notices that “hello.html” references “http://mysite.com/hello.lzx”
(a) The browser requests “hello.lzx” from mysite.com
(b) The Laszlo Presentation (LPS) finds “hello.lzx,” creates a SWF and sends it to the browser.
3. Your app has referenced a data source (an XML file on the server’s local file system, on any other server, or dynamically created XML develivered over HTTP)
(a) The LPS-generated SWF makes a native Flash call that causes the browser to send a request to LPS
(b) LPS fetches the data (which is in standard XML). It transforms the data into native Flash goop and sends it back to the browser.
(c) It appears in the SWF auto-magically datamapped to the appropriate view or whatever you asked it to do in your LZX file.
What Laszlo has done is to normalize the Flash runtime for the creation of applications. It all ends up running in the Flash player, but there is a bunch of Laszlo magic that lets you focus on application development and interface design. Laszlo provides a framework, which includes a view system, data mapping, layouts, constraints and all sorts of useful stuff.
One last technical note, LPS does a bunch of smart caching. If an LZX file or the data source hasn’t changed, LPS efficiently delivers the same bunch of bits it created for the previous request. Incremental compiles are achieved by breaking up your app into separate files, typically using the <library> tag. Then LPS only compiles the file that has changed.
tag definitely helps, but I was thinking of finer-grained caching on the server side and level caching on the client side.
Can we save the generated SWF file for deployment without the server if it has no interprocess communication involved?
Sarah, thanks for the tips. Unfortunately I don’t have an internet connection in my new apartment right now, but I will try to dowload that to my usb drive and check it out later. I was able to get the gallery application to run by instantiating my classes with javascript statements, though I would prefer to be able build the app with embedded XML, or, even better, apply a one-time pass through the XML to generate a static UI that will never change.
For the version that is connected to the server, I load the data for each gallery item dynamically, but I want to put this swf on a CD or web site that will not have a Laszlo installation available.
I sent you an email with the swf, but made some good improvements last night after sending it. If you are interested in seeing how I am using Laszlo, I made a 10 minute video about the project available here:
http://www.getafile.com/cgi-bin/merlot/get/UVc/Laszlo/Laszlo.wmv
It shows the gallery application running with the Laszlo backend server, so its fully functional.
Take care,
Josh
How to produce a swf with laszlo…
but non in fly but in solid, i have no my private WWW server, i need a swf to embed in site
[php]
sorry for chaotical and bad english..
Okay, to get a straight SWF file:
Open the editor and pick an edit window. I usually go ‘Laszlo in 10 Minutes’ to ‘Introduction’ to ‘Hello World,’ just because it’s at the top of the list.
Put your code in and update.
If necessary, stretch the frame that has your applet so you can see an empty space on it.
I’m not sure what the protocol for this is in IE, since I only use Firefox. On the frame with the applet, right-click the empty space and choose ‘This Frame’ to ‘Open Frame in New Window.’
In the new window, scan the url and erase anything after .lzx. Also, there’ll be a double-slash somewhere in the URL. Make it a single, then load the new URL.
You can fiddle with the options a bit, but they’re not really worth messing with. Just click SOLO.
On the next screen, just click CONTINUE. There’s nothing you need here.
After that, you have a link to the SWF at the top. You can save it from there with a real name instead of the garbage IT comes up with. When you press Continue, it’ll give you the HTML code to implement it on your webpage. Tada.