Solo is Simple, part two
We've seen how to deploy a simple SOLO application, now let's look at some more complex situations.
Runtime Resources
-----------------
If the application uses any resources at runtime,
you need to put them in the deployment directory also. Recall that runtime resources are referenced by http. Resources
that are referenced by a simple path (without http) are complied into the application, so you do not need to copy
those to the deploy directory.
For example
---------
[code lang="xml"]
[/code]
---------------
In the deploy directory you would need to create a directory named "resources" and put a copy of sunset.jpg in it.
Supported media types
----------------------
Because of limitations of the Flash player, resources used by SOLO applications must be in Flash (.swf), JPEG or MP3
format. If your application uses resources in another format, such as .gif, you can either deploy your application using
the OpenLaszlo Server (in other words, not SOLO), or you can transcode them beforehand into one of the supported formats.
(Transcoding is beyond the scope of this tip, other than to say that transcoding tools are available on the web.)
SOLO applications with dynamic libraries
-----------------------------------------
Dynamically loaded libraries, denoted by the <import> tag, are incorporated in to the application at runtime. When you compile a SOLO application
that uses dynamically loaded libraries, the compiler creates a directory called build, and within build it creates a subdirectory to
store the compiled libraries that will be used by your program. So, for example, consider the application blue.lzx:
----------------
[code lang="xml"]
[/code]
-----------
blueblox.lzx:
------------
----------
When you browse blue.lzx in the development directory, the compiler creates the build directory. In the build directory you'll find a subdirectory
called blue, in that is bluebox.lzx.swf. Copy the build directory to the deployment directory. That's all there is to it.
Resources from a different domain
----------------------------------
If you use any resources that are not served from the same domain as your SOLO application, you need to create or edit the crossdomain.xml
file at the top level of the domain from which they are served. This is a requirement of the Flash player, and is necessary to prevent unauthorized
access.
Here is a sample crossdomain.xml file:
------------
-------------
For instance, say you have a Laszlo application that uses art assets from a remote source:
<resource name="prettypicture" src="http://someURL/picture.gif"> where someURL is different from where the application is served.
There is a properly configured crossdomain.xml file at the laszlosystems.com site, which allows this to work. In the example below, note that the resource is not fetched from the server until the button is clicked:
-----------
-------------
data="/files/remote.lzx.swf" width="500" height="300">
(Thanks to Andrew Wooldridge for the inspiration for this example!)
Applications that communicate with the browser
-----------------------------------------------
If your application uses the Laszlo facilities for communication with the browser (as explained in the Browser Integration chapter of the Developer's
Guide), you need to place a copy of the file embed.js in the deploy directory, and you also must make sure that the html wrapper for
your application correctly calls it. Finally, you need to modify the wrapper so that query string arguments are correctly passed from the URL to
the SOLO application when you invoke it.
The usual way to create this wrapper is to compile the application with ?lzt=html (instead of lzt=html-object).
An html "wrapper" page to contain your application might look something like the one below. Remember, don't cut and paste this;
use the OpenLaszlo Server to create your own wrapper:
---------------
[code]
< !DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
href="http://www.laszlosystems.com/favicon.ico">
[/code]
--------------
Notice lzEmbed line that passes all of the query parameters down to the Laszlo application undamaged:
lzEmbed({url: 'main.lzx.swf?'+window.location.search.substring(1),
bgcolor: '#ffffff', width: '100%', height: '100%'});
The thing that's different is the alteration to main.lzx.swf? from main.lzx?lzt=swf and the addition of
'+window.location.search.substring(1)'
A simple script for turnkey SOLO deployment
-------------------------------------------
Depending on the complexity of your application, you may have a nice little bundle of stuff to get up to the deployment server:
- the main application (
.lzx.swfextension) - the wrapper page that embeds the application
- one or more directories containing run-time resources
- "build" directory containing compiled libraries
- the
embed.jsfile
One easy way deploy such an application is to use a script that builds, compresses and transfers
an archive file. The example below uses a UNIX shell script, which will also work of course on a Windows machine with cgwin installed:
A SOLO deployment build script might look like:
---------------
#!/bin/sh
rm build.tar.gz #remove any earlier versions
wget \
'http://localhost:8080/lps-3.0/main.lzx?lzproxied=false&lzt=swf' \
-O main.lzx.swf #fetch and compile the Laszlo application
tar -rvf build.tar main.lzx.swf #the application
tar -cvf build.tar index.html #html wrapper
tar -rvf build.tar resources # runtime resources
tar -rvf build.tar build #dynamically loaded libraries
# code that enables browser javascript to Laszlo communication
tar -rvf build.tar lps/includes/embed.js
gzip build.tar
scp build.tar.gz targetServer: #
------------------
After executing, simply untar on the other side.
Limitations on SOLO applications
-----------------------------------------
We've noted above that SOLO applications can only include resources in swf, JPEG, or MP3 format. Another limitation is that SOLO applications cannot use Laszlo's persistent connection, XML-RPC, or SOAP capabilities. See the Developer's Guide for details.