Advertising Temporarily Suspended

My blog has always been purely about geeky computer stuff: RIAs, Rails, Linux, etc. So I was quite surprised to browse to it today and find a political ad regarding one of California’s propositions in the left-hand sidebar. (Note to non-Californians: proposition == referendum). Google serves these ads directly, through their AdSense program. I have no control over what ads gets served. Until now, they have usually been relevant, since Google parses my blog and matches ads based on keywords it finds.

I apologize to my readers for this intrusion.

Since one doesn’t talk about politics in polite company, I’ve decided to remove all ads from my blog until after tomorrow – election day – when no doubt Google will revert to serving discreet text ads packed with warm acronyms.

Overwriting Laszlo Foundation Class Methods

I often find myself needing to overwrite a method in one of the Laszlo Foundation Classes. For example, there might be a problem setting a background color on a text field, and I want to override the setter method for the text class’s text bgcolor in order to debug it.

In OpenLaszlo 4.0 and below, the syntax for overwriting a method at run-time was:

        LzText.prototype.setBGColor = function (bgc) { ... }

With OpenLaszlo 4.0.12 and above, that has changed to:

LzText.prototype.addProperty("setBGColor", function (bgc) { ... }); // 4.0.12

lz.text.prototype.addProperty("setBGColor", function (bgc) { ... }); // 4.1 and up

LZX does provide a class construct, and you can certainly subclass the text class and override the setText method that way, but that won’t let you overwrite the setText method for all existing instances of LzText/lz.text. Luckily, JavaScript allows you to define methods on-the-fly, as shown above. This applies to SWF7, SWF8 and DHTML runtimes. Unfortunately in SWF9, it’s not possible overwrite a method on-the-fly.

There are some gotchas here:

  • The debugger is not accessible within LFC methods. If you try to Debug.write, from within one, the application will fail and become unresponsive. The best thing to do is to write your own text field that replaces the debugger, and write to that. Make sure to test for the existence of that text field first.
  • Any errors in your added LFC methods will break the application or the class. You won’t always get useful feedback in the debugger.
  • You can’t use the super reference to refer to the superclass (since you’re not using LZX’s class construct). You will need to copy-and-paste the original source for that method from the LFC. How do you get the original source for an LFC? Easy. Look it up on the OpenLaszlo Subversion repository. You’ll want the right one for the version of OpenLaszlo you’re developing on. e.g. To see the source for the setBGColor method of lz.text in OpenLaszlo 4.1.1, you would need to look at LaszloView.lzs, since lz.text inherits from that.

This technique will work on your own LZX classes too, and packaged LZX components (e.g. window, button, etc.). It’s just not essential for those, since you can manipulate the LZX code directly.

Note that this is not how you should define/overwrite methods in your applications generally; it’s a debugging technique not a best-practice.

To see the whole thing in context, here’s an example test case that works on a recent OpenLaszlo 4.2.x nightly build.