Dynamic Flash

As my hosting is coming up for renewal, I’m going to take the opportunity to move servers this weekend. 34sp.com have been very good over the past two years (and are fabulous value for money) but getting new bits and bobs installed on the server is impossible as they’re locked into whatever the latest version of Plesk (server-management tool) offers.

I’m now moving to Hostway.co.uk (Hostway.com if you’re on the other side of the pond), with whom we host Featurecreep’s servers. If you’re looking for a professional hosting package with unrivaled support, I’d urge you to give them a try. They’ve been great about modifying their PHP build scripts to include Sablotron (XSLT processing) and XML DOM, as well as helping out with just about anything else we’ve ever needed. Oh, and I’m not on the take before you ask, its just that good service deserves to be shouted about!

Update: Forgot to mention that I’ll be moving from dynamicflash.co.uk to dynamicflash.com. I think I can get both (and dynamicflash.net) to work equally well, but I won’t know until I try.

Update 2: Server move is now completed. Took longer than I thought to get it all set up. I’ve yet to make dynamicflash.co.uk properly resolve to the new server, so I’ve set up temporary redirection. Unfortunately this probably won’t work with most feed readers or aggregators, so please update them with the new feed URLs (available top-right of the page).

Whilst flicking through my favourite blogs over a nice glass of red wine, I came across a post by Andy Budd discussing appropriate use of headings in semantic mark-up. Since Andy has highlighted the issue far more eloquently than I could, I’m not even going to try explaining the whole issue here – I’d suggest you read his article before carrying on.

The basic conclusion of Andy’s post is that slapping your site title in an h1 tag is not necessarily something you should be doing if you’re aiming to give your mark-up maximum meaning. We see a lot of sites these days that are striving for semantic mark-up but “abuse” the h1 tag, using some crazy CSS like the following to display a header image instead of the actual heading.

[css] h1 { text-indent: -1000em; width: 800px; height: 60px; background: url(header.gif) no-repeat; }[/css]

This gives the heading text a huge negative indent to push it off the page whilst still keeping it accessible for screen readers, and places a background image in its place.

Andy argues that the h1 tag should be used…

…to describe the structure and content of the current page, not to describe the structure of the site or how this particular page fits into a larger hierarchy.

To be honest, I’m not entirely sure where I stand on this issue. The number one question that springs to mind is which tag we should use for the site title if the h1 tag is inappropriate? Surely it has to be somewhere in the mark-up (unless the title of the site isn’t important?) but the only other real alternative is the <title> tag, and that’s generally a combination of the site title and the page title. Is that good enough? If it is, does the fact that those using screen readers have to make an educated guess at the title of the site is that acceptable? If it’s not good enough, what are we left with?

Introduced in the Flash MX 2004 7.2 updater, Macromedia’s Delegate class was a neat solution to having event listeners called in a given scope. Joey Lott improved on this with his Proxy class, allowing you to optionally send additional arguments to your event handler.

Unfortunately, when using either of these classes it is difficult to remove an event listener from an object, because the actual event listener is an anonymous function which calls your target event handler method in the specified scope. If you want to remove such an event listener, you basically have two options, dicussed below.

Option 1: Storing a local reference

If you’re only dealing with a handful of event listeners, you could take the option of manually storing a reference to your ‘delegate’ functions, which you can then later use to remove the event listener.

The example below is a little contrived, but the basic scenario is that you want to listen for the first change in a TextArea component in a MovieClip.

import mx.controls.TextArea;
import mx.utils.Delegate;
 
class MMDelegateTest {
  private var _delegate:Function;
  private var _textArea:TextArea;
 
  public function MMDelegateTest (textArea:TextArea) {
    _textArea = textArea;
    _delegate = Delegate.create(this, onTextAreaChange);
    _textArea.addEventListener("change", _delegate);
  }
 
  private function onTextAreaChange(event:Object) : Void {
    trace("MMDelegateTest.onTextAreaChange");
 
    _textArea.removeEventListener("change", _delegate);
    delete _delegate;
  }
}

Here we create the delegate function and store a reference to it in the private _delegate property. We then use the reference when setting up the event listener, and also again in our event handler to remove the event listener after the first call.

This method works both with Macromedia’s Delegate class and Joey’s Proxy class, but can get very hard to manage if you’re dealing with more than a few event listeners. You also have to manually delete the reference to the delegate function when removing the event listener, otherwise the delegate function won’t get garbage collected. Whether this represent a serious concern for you depends on how many delegate functions you’re going to be creating, but memory leakage is never a good thing.

Option 2: Using a temporary object

If storing local references seems like too much of a hassle, you could always store a reference to the delegate function in a temporary object. Then, using Joey’s Proxy class, you could pass this temporary object to the target event handler as one of the extra arguments that you can get up when calling the Proxy.create() method.

import mx.controls.TextArea;
import ascb.util.Proxy;
 
class JLDelegateTest {
  private var _textArea:TextArea;
 
  public function JLDelegateTest(textArea:TextArea) {
    _textArea = textArea;
    var obj:Object = new Object();
    obj.delegate = Proxy.create(this, onTextAreaChange, obj);
    _textArea.addEventListener("change", obj.delegate);
  }
 
  private function onTextAreaChange(event:Object, obj:Object) : Void {
    trace("JLDelegateTest.onTextAreaChange");
    _textArea.removeEventListener("change", obj.delegate);
  }
}

Here you don’t have to worry about storing local references, because a reference to the delegate function is passed to the event handler method as the delegate property of the obj parameter. You also don’t have to worry about deleting the stored reference to the delegate function, since the temporary object will be marked for garbage collection once the event listener is removed.

However, having to create a temporary object every time I was creating an event listener that I might want to remove in the future was unnecessarily cluttering up my code. Also, I would also have to explain the solution (and exactly why it works) to every developer who works on a piece of my code, so I set about finding a better solution.

A better solution?

In the end, the solution that works for me is simple – just have the delegate function pass a reference to itself as the final argument to the real event handler. Presenting the DynamicFlash Delegate class.

import mx.controls.TextArea;
import com.dynamicflash.utils.Delegate;
 
class DFDelegateTest {
  private var _textArea:TextArea;
 
  public function DFDelegateTest(textArea:TextArea) {
    _textArea = textArea;
    _textArea.addEventListener("change", Delegate.create(this, onTextAreaChange));
  }
 
  private function onTextAreaChange(event:Object, delegate:Function) : Void {
    trace("DFDelegateTest.onTextAreaChange");
    _textArea.removeEventListener("change", delegate);
  }
}

So there you have it. No local references, no temporary objects, just plain and simple event listener obliteration. As with Joey’s class, you can specify any number of additional arguments to be sent to the event handler method when it is called, but there is always a final argument sent that contains a reference to the delegate function that can be used to remove the event listener directly.

Event handlers that aren’t interested in the final argument needn’t even declare it as a parameter in their parameter list, but those that are can use that reference to remove the event listener if necessary. As a bonus, you can swap out Macromedia’s Delegate class for this one using simple search & replace as they have the same interface – just replace every instance of ‘mx.utils.Delegate’ in your code with ‘com.dynamicflash.utils.Delegate’ and you’re good to go.

Over the past 6 months or so I have been utterly consumed by the task of designing and building our content management system. The administration interface is written entirely in Actionscript 2.0, and I have learned to love that language like a brother¹ – I don’t think I’ll ever touch a line of Actionscript 1 again if I can help it.

In the administration application, we have a data class that represents a page that has an extensible collection of ‘properties’ (as we call them in the system – sorry about the confusing nomenclature) along with methods to allow properties to be added. The class also has a number of regular private properties, along with Actionscript 2.0 style getter / setter methods for those properties.

A super-simplified version of this class might look something like this:

class Page {
    private var __properties:Array;
 
    private var __title:String;
    private var __path:String;
 
    public function get title():String { return __title; }
    public function get path():String { return __path; }
 
    public function Page(Void) {
        __properties = new Array();
    }
 
    public function addProperty(prop:Property) : Void {
        __properties.push(prop);
    }
}

While the above may look fine (especially if you only code in AS2), you’ll find that the getter / setter methods don’t actually work on objects of that class.

Half a day and several strong cups of tea later, I finally remembered that the underlying Object class has a method called addProperty(), and that method is what you use to register getter / setter functions for an object in AS1. Actionscript 2.0 classes compile down to the same byte-code instructions as AS1, so your getter / setter functions actually end up as __get_PROPERTY() and __set_PROPERTY() and uses Object.addProperty() to register them against PROPERTY in your class objects.

So, because I has implemented a method called addProperty() in my own class, and because all classes are ancestors of Object, I was hiding the Object.addProperty() method, which meant that the getter /setters were never registered.

Having worked exclusively with Actionscript 2.0 for so long, it took me a good half day to figure out why this was happening. I just wanted to post this up here as a reminder so that others don’t make the same mistake! It’s certainly an easy mistake to make now that we have a proper syntax for getter/setter methods instead of having to register them ourselves. Certainly a compiler warning would have been nice!

–Update–

Typical! Having just added syntax highlighting to this blog, I can see that the addProperty() method is now highlighted as a keyword. If I’d used an editor that did this in the first place, maybe I could have saved myself from this whole sorry debacle. Sadly there’s a distinct lack of good Actionscript 2.0 editors for OS X, basically it’s TextWrangler or bust!

It’s been a long time since Foundation PHP for Flash was available on the market, and although Friends of Ed are currently doing a rewrite, no-one from the original PHP for Flash team (Alan, Gaynor or myself) is involved, so I’m slightly concerned about how it’s going to turn out. That’s not to say that it won’t be great, just that the original book has such a following (people are still clamoring for copies now, over 2 years after it went out of print) and I have such fond memories of writing and supporting the book that I don’t want to see it fail.

To counteract this, I’m contemplating a gradual rewrite of the chapters from the original Foundation PHP for Flash, updating them for Flash MX 2004 and PHP 4 (and PHP 5 where it differs) so that they make sense in todays world. I intend to publish the chapters freely on this site for everyone to read, but I can only really do that if there is enough interest to make it worth my while. Let me know (via comments) if you’re interested.