Building and Deploying Lasso Apps

Session held at LDC Toronto May 2012.
Presented by Jono Guthrie, LassoSoft Inc

What is a LassoApp?

A LassoApp is a means for bundling source files, HTML, images and other media types into a single deployable unit called a LassoApp.

Why put code in my webroot?

In order to use LassoApps effectively, you need to know there are a number of reasons why you’d *not* use LassoApps.

• Code in your webroot can be quick to throw a solution together
• A more “traditional” way of working
• Very relaxed rules surround development in this way
• You don’t have to think, just create and run

So you tell me LassoApps are cool. Prove it.

LassoApps have evolved substantially from pre-Lasso 9 days. Many of the coolest features of L9 LassoApps are new, while retaining all of the strengths of the old.

Installation: _install.lasso

The first time a LassoApp is loaded by the instance, it will execute any files with filename beginning with “_install.” For example, an install file that performs a specific task, such as creating database required by the app, could be named _install.create_dbs.lasso.

Initialization: _init.lasso

Another special file type is the “_init.” file. While _install.lasso will only ever execute once at installation, a file such as _init.lasso will be executed every time the instance starts. Initialization files are used to define all of the types, traits and methods used within the application, along with any atBegin blocks.

Defining methods, types etc is best done at startup on a production system as re-defining a method can have an impact on performance, potentially leading to bottlenecks in your application. 

Content representation and nice URL’s

Here’s a bunch of new stuff that is all related.

Let’s start with looking at the structure of a LassoApp.

In the pre-9 days, LassoApps had really ugly URL’s like “/myLassoApp.137.LassoApp” to represent “/contact/detail.lasso” for example

In L9, this would be “/lasso9/myLassoApp/contact/detail” 

Firstly, note the absence of an obfuscated URL. It’s plain, and represents exactly the directory structure you have in reality.

Second, there’s no extension. Yes that’s right, no extension. Lasso will execute it and represent it as HTML by default. You can force it to HTML if you wish by naming the file detail[html].lasso

So the contents of the detail[html].lasso are as follows:

[lassoapp_include_current('/contact/dummyRecord.lasso')]
<table>
	<tr>
		<td>Name</td>
		<td>[$data->find('FirstName')] [$data->find('LastName')]</td>
		<td rowspan="6"><img src="/lasso9/myLassoApp/contact/detail.jpg"></td>
	</tr>
	<tr>
		<td>Title</td>
		<td>[$data->find('Title')]</td>
	</tr>
	<tr>
		<td>Phone</td>
		<td>[$data->find('Phone')]</td>
	</tr>
	<tr>
		<td>Address</td>
		<td>[$data->find('Address')]</td>
	</tr>
	<tr>
		<td>City</td>
		<td>[$data->find('City')]</td>
	</tr>
	<tr>
		<td>Country</td>
		<td>[$data->find('Country')]</td>
	</tr>
</table>

Note that there’s a reference to “detail.jpg”, and yet there’s no detail.jpg only a detail[jpg].lasso.

The contents of this file are:

lassoapp_include_current('/contact/dummyRecord.lasso')
local(x = image(lassoapp_include_current('/images/'+$data->find('img'))->bytes))
return #x->bytes

 

Now, you can quite happily have jpg, png, css files etc - all this demonstrates is that LassoApps are not limited to textural generation of information but can generate other data types as well.

In the demo, check out:

http://:8083/lasso9/myLassoApp/contact/detail.xhr

http://:8083/lasso9/myLassoApp/contact/detail.xml

(Note, these URL’s are running from my own LassoLabs runtime config, your URL will vary)

It’s compiled (if you choose)

OK so compiling a LassoApp is not really new - we’ve been able to do it for years. What *is* new is that we can run *as* a LassoApp uncompiled, something that was simply not possible in prior versions. Previously it was a hit and miss, compile, fix, recompile - a major issue for larger systems.

If you think back to the previous examples, we’ve already seen this in action. That code was all running from the LassoApp directory and taking advantage of LassoApp-specific features.

When you compile your LassoApp, the generated file looks on the surface the same, but is completely different. Even when compiled the URL’s are all the same.

It’s portable

One of the significant advantages of Lasso 9’s LassoApps are in the ability to quickly move or clone the solution. Because it’s self contained, it’s one file to move. Because it can self-configure and self-initialize, you can set it up to quickly deploy on new hardware.

It’s distributable

So let’s consider the scenario where you’ve written a LassoApp, and you want to sell this app and yet don’t want to give away the source, your intellectual property. It’s quite simple: When you want to distribute your application, you’re leveraging the same benefits mentioned with respect to portability. You set it up to self configure (set up datasource structure, pre-populate seed data), initialize on load (data types etc), and require license to run. 

All you need to deliver to the client is the single compiled file.

Think “High Availability”

And again, high availability: You want to add a new node to your HA cluster, it’s as simple as adding the LassoApp to a new instance on a VM or physical server, and with a little config of your web server and Lasso instance and you’re up and running.

You don’t have to stop using webroot!

With all this, at no point do you need to stop using the webroot for “standard” files - lasso or otherwise. You have the complete freedom to mix and match: multiple LassoApps working together; leveraging webroot config files for specific environmental settings; custom image directories; vhost specific CSS; the list is only bounded by your imagination. The point is that you are not restricted to just one mode or the other.

Your choice is to simply choose what’s best for you.

Further reading

http://www.lassosoft.com/Language-Guide-Lasso-Apps

Linked files

myLassoApp.zip - put this in your LassoLab "LassoApps" directory, create a run config and play!

Author: Jono Guthrie
Created: 26 May 2012
Last Modified: 26 May 2012