The Most Useful Firefox Add-on Ever?

There’s a bunch of different tools, add-ons and plugins that I find handy for web and RIA development. However, in terms of sheer usefulness, I would have to say that one stands out above all others: The Firefox Clear Cache Button Add-on:

Clear Cache Button

The Clear Cache Button does exactly as the name suggests, and it does nothing else. It doesn’t clear your cookies, history or any private data at all. It just clears the browser cache. And because it’s a toolbar button, it’s right there. You don’t need to click through a barrage of menus, dialogs and radio buttons.

Browsers are quirky in the way they cache certain types of content. Sometimes images, JavaScript files, CSS files or even SWFs may get pulled from browser cache, without the browser even re-requesting them to see if there is an upated version (which of course, has  just been updated).  Now browsers do provide a fairly standard way to clear cache (via menus), but over the years the default options have come to include clearing your history and cookies – things that improve productivity, and you don’t really want to lose. You can selectively disable things you don’t wish to clear, but it’s time-consuming.

I swear I can see the little broom icon on the button in my toolbar fading, as a result of its frequent use.

Debugging SOLO Applications

The OpenLaszlo debugger is a very versatile tool. You can use it for everything from tracing output, to analyzing the state of objects within your application at runtime, to tracking-down memory leaks. The debugger requires the OpenLaszlo server to be present, but works with SOLO applications – provided the SOLO application can access server. Naturally, while developing a SOLO OpenLaszlo application, you want to have the full capabilities of the debugger available to you.

To achieve this your development workflow should involve:

  1. Make sure the debugger is enabled in the canvas (debug=”true”).
  2. Change your LZX source file(s).
  3. Recompile by accessing the application in your browser (i.e. http://localhost:8080/lps-version/…/my-app.lzx).
  4. Use the debugger.

The above will work fine for both SOLO and proxied OpenLaszlo applications, since you’re accessing the LZX directly. What happens when you want to have a custom HTML wrapper page? You may have to access your OpenLaszlo application via a wrapper page if, say, you pass parameters from the wrapper page to your own application. In a SOLO application, your SWF will probably be embedded in a custom wrapper page like the following. (This is the new 4.1 embed code, the embed code for 4.0.12 looks a little different):

lz.embed.swf({url: 'main.lzx.lzr=swf8.swf?myparam=123', bgcolor: '#ffffff', width: '800', height: '600', id: 'lzapp', accessible: 'false'});

As an example, I’ve added a myparam paramaNote the direct reference to the compiled SWF file. If you run the above application with the debugger open, it will throw the following error:

Debugger cannot contact LPS server, switching to SOLO mode.

At this point, the debugger can trace output from Debug.write() statements in your code, but it won’t be able to execute arbitrary code you type into it, or many of its other useful features. To fix this, when developing SOLO applications within a custom wraper page, you should embed the application as follows:

lz.embed.swf({url: 'main.lzx?lzt=swf&lzr=swf8&myparam=123', bgcolor: '#ffffff', width: '800', height: '600', id: 'lzapp', accessible: 'false'});

Since you specify that the application is SOLO in your LZX code, the returned SWF will be a SOLO OpenLaszlo application, but it will have access to the server too. I wouldn’t recommend using the command-line compiler for development.

Migrating LZX Code to OpenLaszlo 4.1

I was recently porting some LZX code in OpenLaszlo Training materials from 4.0.12 to 4.1, and stumbled upon a few issues, which I thought I’d post here as a reference.

Don’t use <method event=””> Syntax

The <handler name=””>syntax was introduced to replace the <method event=””> syntax some time ago. With 4.1, I found that the compiler/debugger could get confused if you continued to use the old syntax in some cases. Sometimes the error messages were not useful. In short, replace:

<method event="onevent">
...
</method>

… with:

<handler name="onevent">
...
</handler>

Delegate Method Arguments

Any method you call with a delegate must now have a defined argument. This is in preparation for future compatibility with SWF9. Check these out colabioclipanama2019. In short, if you write:

<script>
new LzDelegate(canvas, "myMethod", ds, "ondata");
</script>

<method name="myMethod">
...
</method>

… you should define your method as shown below:

<method name="myMethod" args="arg">
...
</method>

The New “lz” Namespace

In OpenLaszlo 4.0.x, there was a global object that contained references to classes, colors and global tokens. In OpenLaszlo 4.1, there is now an lz object that replaces this for class definitions. Here’s salbreux-pesage an example for you to better understanding.It creates a virtual namespace. So if you need to procedurally instantiate an OpenLaszlo window, instead of writing:

new window(canvas, {width:300, height:300});

… you now write:

new lz.window(canvas, {width:300, height:300});

If you need to paramaterize the name of a class, you used to write:

var classname = "window";
new global[classname](canvas, {width:300, height:300});

… instead, now you would write:

var classname = "window";
new lz[classname](canvas, {width:300, height:300})
;

Those are the main issues I ran into. Otherwise code written for OpenLaszlo 4.0.12 seems to run fine on 4.1.