01.23.06

Subversion Log Viewer

Posted on January 23rd, 2006 in Sightings, Announcements by Oliver

SVN Viewer thumbnail

You may have noticed that the subversion log that’s linked to from the download page is a year out of date. Well, so I did I, and I decided to do something about it. Browse on over to the OpenLaszlo Subversion log viewer, and you can see the most recent twenty changes, along with the friendly faces of the people who commited them.

Of course, the command line subversion tool works too:
svn log http://svn.openlaszlo.org/openlaszlo/trunk.

01.17.06

Announcing the OpenLaszlo Rails Plugin

Posted on January 17th, 2006 in Announcements by Oliver

The OpenLaszlo Rails plugin makes it easy to use OpenLaszlo client-side applications with Rails. It includes generators and scaffolding for creating OpenLaszlo applications, connecting them to Rails REST controllers, and displaying them within Rails views.

For example, the following shell command will create a Rails model named Contact, a REST controller named ContactController, an OpenLaszlo application named applet, and a view named contact/applet.
> script/generate applet contact applet

At this point the applet will automatically display records that it retrieves, via the controller, from the model.

More Info

You can install the plugin in a rails application by using the Rails plugin script:
> script/plugin install svn://rubyforge.org/var/svn/laszlo-plugin/tags/openlaszlo

The OpenLaszlo plugin project page contains additional documentation.

It’s that simple!

In fact, here is all you need to type, from start to finish, in order to (1) install the OpenLaszlo plugin and its dependencies, (2) create a Rails application, (3) create an OpenLaszlo application that is configured to display rows from a database table, (4) create a view that holds the OpenLaszlo application, and (5) create a controller for the application to talk to (using REST). This assumes you’ve already installed Ruby, Rails, MySQL (or another database), and OpenLaszlo.
> gem install ropenlaszlo
> rails contacts
> cd contacts
# (update config/database.yaml with your database configuration settings here)
> script/plugin install svn://rubyforge.org/var/svn/laszlo-plugin/tags/openlaszlo
> script/generate applet contact applet
> rake
> script/server
# open "http://localhost:3000/contacts/applet" in your browser

Update: Changed the svn URL from install svn://rubyforge.org/var/svn/laszlo-plugin/trunk to install svn://rubyforge.org/var/svn/laszlo-plugin/tags/openlaszlo. The other URL still works, but may get you an untested version.

01.11.06

ROpenLaszlo is available as a Ruby Gem

Posted on January 11th, 2006 in Announcements by Oliver

The “OpenLaszlo” module that was announced a few days ago is now available as a Ruby gem. This means that installing it on your system is as simple as typing gem install ropenlaszlo — assuming you’ve already got Ruby and Rubygems.

This means it’s easier than ever to write a build or deployment script for a site that includes OpenLaszlo applications. It also paves the way for integrating OpenLaszlo and Rails, as discussed here.

The new home page for the ROpenLaszlo gem is here.

01.09.06

Another Approach to State

Posted on January 9th, 2006 in Documentation by Oliver

The OpenLaszlo platform contains a <state> tag. A <state> encapsulates a collection of properties (methods and attributes) and children that can be atomically attached to or removed from a node during program execution. This is actually pretty powerful, especially since a state can contain constraints. This is how dragging is implemented, for instance.

OpenLaszlo <state>s are independent from each other. Any number of <state>s may be applied to a view at once, or none.

In problem domains, some states really do combine this way. For example, a view may be being dragged, or not, independently of whether it contains unsaved data or not; and so on.

But there’s another sense of “state”, which is the state in a state machine. These states are mutually exclusive1. And they’re a pain to implement with the <state> tag. You end up writing a code that turns on one state and turns off the others, in order to switch from one state-machine-state to another. Note the verbosity of the three state-changing lines in the fragment below:
<view>
  <state name="s1">...</state>
  <state name="s2">...</state>
  <state name="s3">..</state>

  ...s1.apply(); s2.remove(); s3.remove(); ...
  ...s1.remove(); s2.apply(); s3.remove(); ...
  ...s1.remove(); s2.remove(); s3.apply(); ...
</view>
Here’s the cool thing, though. You can turn the states on and off automatically with constraints. Just add an attribute that names the state, and make the states conditional on the value of that attribute[2]:
<view>
  <attribute name="myState" type="string" value="s1"/>

  <state apply="${this.myState=='s1'}">...</state>
  <state apply="${this.myState=='s2'}">...</state>
  <state apply="${this.myState=='s3'}">...</state>

  ...this.setAttribute('myState', 's1'); ...
  ...this.setAttribute('myState', 's2'); ...
  ...this.setAttribute('myState', 's3'); ...
In fact, if the states are only used to hide and show views and layouts (and not to attach methods and attributes), you don’t even need the <state> tag at all. You can simply conditionalize the views’ visibility on the value of the attribute that holds the state:
<view visible="${this.myState=='s1'}">...</view>
<button visible="${this.myState=='s2'}">...</view>
<text visible="${this.myState=='s3'}">...</view>

It gets better. The views don’t even need to be in the same node that holds the state variable. In expialidocio.us, I create a global “application state” object, and constrain views all over the canvas to the value of its “state” attribute:

<node id="application">
  <attribute name="state" type="string" value="login"/>
</node>
...
<loginView visible="${application.state == 'login'}"/>
<view id="progress" visible="${application.state == 'waiting'}"/>
<view id="username" visible="${application.state == 'running'}">...

You can switch the visibility of views at any level of hierarchy, conditional on the value of application.state or other state variables. You can also switch the values of other attributes, such as position or opacity. And finally, you can conditionalize these attributes on more complex expressions, such as whether an application is either in “login” state or “running”.

<view visible="${application.state == 'login' || application.state == 'running'"$}"/>
<view opacity="${application.state == 'running' ? 1.0 : 0.5"/>
<view y="${application.state == 'running' ? 0 : otherView.y+otherView.height}"/>
<view visible="${application.state == 'login' &amp;&amp; login.hostType == 'remote'}"/>

Notes

1 States are mutually exclusive in the case of a deterministic state machine. And this is what’s usually used for modeling software and user interface components.

2 You can use numbers for state values instead of strings, but I recommend strings for readability, unless you can prove that it makes a performance difference to your application. And in a real application I use strings such as “login”, “processing”, and “running”, instead of “s1″, “s2″, etc.

01.08.06

Conditionalize Visibility with Constraints

Posted on January 8th, 2006 in Documentation by Oliver

The button bar on my project page has a “Powered by OpenLaszlo” watermark. It’s at the right edge of the window. Positioning it there was easy1:
<text x="${canvas.width-this.width}"><u>Powered by OpenLaszlo</u></text>

A problem with this implementation is that the logo overlaps the search field when the window is narrow:

I wanted it to disappear instead.

Here’s the version that does that. The new code is the “visible” attribute, on the first line.
<text visible="${this.x > searchField.x+searchField.right}"
      x="${canvas.width-this.width"><u>Powered by OpenLaszlo</u></text>

This hides the view whenever the layout rules or (in this case) other constraints would have moved it over the view to its left. Here I’ve hardwired the name of the view to its left, but for this application, that’s okay.

1 The actual source is longer than this, since it has a click handler to go to the OpenLaszlo home page, and mouse handers to dim the watermark when the mouse isn’t over it. But this much handles the visuals.

01.05.06

Deploying OpenLaszlo Applications with Rake

Posted on January 5th, 2006 in Documentation by Oliver

Compiling and debugging an OpenLaszlo application is just part of the picture. Often there are assets that need to be compiled into an application, and things that need to be done with the application binary once it is complete.

At some point, once you reach a certain level of application or site complexity, you need a build script to automate the build and deployment steps. For side projects, I've been using Rake.

Here's how to use Rake to build an OpenLaszlo application. Once you do this, you'll be able to type rake hello.swf to compile an OpenLaszlo source file. More to the point, Rake can also create whatever other XML and image files your application depends on (provided you tell Rake how to build them), and you'll be able to type commands such as rake deploy to both compile the application and copy to a server -- provided, again, you've told Rake how to do this. There are examples of all of this below.

Installation

First, install Ruby, and Rake. The easiest way to install Rake is to install rubygems and then type gem install rake. If you're on a Mac you'll need to type sudo gem install rake instead. (And if you're on a Mac, you probably already have Ruby. It comes pre-installed.) Update: You should install rubygems. It's now the endorsed way to install the ruby OpenLaszlo module, below.

Second, download openlaszlo.rb, and copy it into a directory on your Ruby library path. (You can examine your library path by executing ruby -e 'puts $:'.) You may need an admin password to do this.1

Second, install the ROpenLaszlo gem:
gem install -r ropenlaszlo
 Finally, you need to set some shell environment variables. OPENLASZLO_HOME is the location of the OpenLaszlo SDK on the file system. If you're using the binary install, set it to /Applications/OpenLaszlo Server 3.1. OPENLASZLO_URL is the URL of the OpenLaszlo server; for example, http://localhost:8080/lps-3.1. You can set these from the shell, or place this in your .bashrc_profile or the equivalent:
export OPENLASZLO_HOME=/Applications/OpenLaszlo Server 3.1
export OPENLASZLO_URL=http://localhost:8080/lps-3.1

That does it for system setup. Here's what you do for each project:

Usage

A project needs to live in a directory inside your OpenLaszlo server directory. For example, if you're using the OpenLaszlo 3.1 binary install on a Mac, you might use to /Applications/OpenLaszlo Server 3.1/Server/lps-3.1/my-apps. I build from a source tree that is synced to ~/laszlo/lps-dev, so I keep my projects in subdirectories of that.

Go ahead and make a new subdirectory inside the server directory, say hello. Put two files in this directory. The first is an OpenLaszlo source file, hello.lzx:
<canvas><text>Hello Rake</text></canvas>
The second is Rakefile:
require 'openlaszlo'
 
require 'openlaszlo'
 
rule '.swf' => '.lzx' do |t|
  puts "Compiling #{t.source} => #{t.name}" if verbose
  OpenLaszlo::compile t.source, :output => t.name
end
Type rake hello.swf into the shell, and you'll get a file hello.swf in the same directory:
> rake hello.swf
(in /Users/oliversteele/laszlo/lps-dev/hello)
Compiling hello.lzx => hello.swf
> ls -l hello.swf
-rw-r--r--   1 oliverst  www  73035 Jan  5 12:49 hello.swf
Execute rake hello.swf, and nothing will happen:
> <kbd>rake hello.swf</kbd>
...until you change the source file or delete hello.swf:
> touch hello.lzx
> rake hello.swf
(in /Users/oliversteele/laszlo/lps-dev/hello)
Compiling hello.lzx => hello.swf

Why Bother?

That was a lot of trouble just to do the same thing you could already do with lzc. Why bother?

One reason is that it's faster. I told you to set the OPENLASZLO_URL environment variable. That tells the OpenLaszlo module (and therefore the Rake task which uses it) to use the OpenLaszlo server to compile applications, and this can be a lot faster than using lzc[2]. For example, on my 1.5MHz PowerBook, rake hello.swf takes 18s, as compared to 35s for lzc hello.lzx.3

Of course, you could get the same speed by using the browser to run your application, and you're doing this anyway when you debug it, so what's are the real advantages?

As with any task automation, they're repeatability, and single-stop shopping. Let's take the second first.

Complex Builds

First, Rake goes beyond browser-based compile and lzc, in that it can be used to build files that the swf file depends on. For example, my home page button bar depends on an XML file for configuration, and some static text images to work around the problem that the Flash player can't apply opacity to client fonts. (And since I've only got a little bit of text in my application, I don't want to bother embedding a font.)

I use a rakefile similar to the one above for this application, but with the following additional lines:
file 'nav.swf' => ['projects.xml', 'label.png']

file 'label.png' do |t|
  sh "convert -background transparent label:'(enter search text here)' #{t.name}"
end

file 'projects.xml' => ['index.rb', 'projects.yaml'] do |t|
  require 'projects.rb'
  make_xml t.name
end

The first line supplements the *.lzx -> *.swf rule above, with the information that this particular file additionally depends on the files projects.xml and label.png. The next two forms tell Rake how to use ImageMagick, and a function defined in another file, to make these.

Now I can execute rake nav.swf to rebuild whichever of label.png, projects.xml, and nav.swf is required.

A word of warning: Unlike the browser-based compiler, Rake doesn't know any more about your source file dependencies than what you tell it. For example, if nav.lzx includes mylib.lzx and functions.js, Rake won't know to recompile nav.swf if either of these files changes (but nav.lzx doesn't). You'll need to add:
file 'nav.swf' => ['mylib.lzx', 'functions.js']
to your rakefile to tell it about them.

Deployment

The other reason to include your OpenLaszlo application builds in a build system is that that way you can automate deployment too. My deployment set consists of HTML files, PHP files, OpenLaszlo swfs, and auxiliary images, some created by hand, and some produced by other tools. I build them all locally, so that I can test them in a staging directory, but at some point I upload them to a web site -- and that's when I notice the typo, and need to do it all again. Adding a deploy task makes this easy:
FILES = %w{index.php header.php footer.php nav.swf}
STAGING_URL = 'ows@osteele.com/staging.osteele.com'
DEPLOYMENT_URL = 'ows@osteele.com/osteele.com'

task :staging => FILES do
  sh "rsync -avz -e ssh #{UPLOADS.join(' ')} #{STAGING_URL}"
end

task :deploy => FILES do
  sh "rsync -avz -e ssh #{UPLOADS.join(' ')} #{DEPLOYMENT_URL}"
end

And now rake deploy builds everything locally, and then copies everything that's changed to a deployment server.

And I can get back to actually writing code.

Updated 2006-01-11: The OpenLaszlo module is now available as a gem.

1 Alternatively, you can add a directory where you have write permission to your search path (add export RUBYLIB=~/lib/ruby to your .bash_profile or equivalent), and copy openlaszlo.rb there.

The OpenLaszlo ruby library is only a day old. After it's baked for a while I'll turn it into a gem, and then these installation instructions will be simpler.

2 First, because it doesn't have to start a JVM process for each compile, and second, because the JVM process doesn't have to load the script cache when it starts up. (Loading the script cache is slow, but compiling without it is even slower.)

3 All of these times are for a recompile -- after the file has been compiled once, and then trivially changed. The initial compile is slower -- sometimes a lot slower -- but isn't as representative of the edit-compile-debug cycle.

01.04.06

Three OpenLaszlo Applets

Posted on January 4th, 2006 in Sightings by Oliver

I wrote a few OpenLaszlo applets over the holidays. I’m calling them “applets” because they aren’t full-fledged transactional applications; nevertheless, I thought they might be interesting to a few developers.

Aargh thumbnail

First, the Aargh! page answers the question, how do you spell “aargh”? It uses statistics from Google, and both an HTML table and an OpenLaszlo application to visualize the result. (Click on the “visualize” button at the top of the table, to switch between them.)

Then, Ben’s roundrectbutton got me excited about using OpenLaszlo for lighter-weight interfaces, so I added a button bar to the top of my home page.

toolbar sampler

expialidocio.us thumbnail

And finally, Jon Udell posted about visualizing del.icio.us tags over time. He uses an Excel spreadsheet to implement the visualization, but I wanted something more interactive. Hence: expialidocio.us.

One of the things I like about OpenLaszlo is that it makes it easy to write small applets like this quickly — because they just aren’t a lot of code.