Random User Tips

For more Articles, Methods, Tags, References and Tutorials see LassoDocs

Articles

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

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.

Comments

Please note that periodically LassoSoft will go through the notes and may incorporate information from them into the documentation. Any submission here gives LassoSoft a non-exclusive license and will be made available in various formats to the Lasso community.

Article Search

Table of Contents

Random User Tips

use_consistent_name

Segment your methods by using a standard name format

category_method_desc such as

client_address

or

client_formmethod

This is easier for you to read, and easier if you will be passing your code to someone else (like adding it to TagSwap)

For more Articles, Methods, Tags, References and Tutorials see LassoDocs