Systeme D

7 September 2006

Avoiding mx.utils.Delegate with ActionScript 1.0

(Warning: this posting contains some references to Proper Programming Techniques in which I will doubtless expose my complete ignorance of same.)

ActionScript 1.0, though lovely in a Perl-like "knock something up and it works" type of way, has a couple of issues... and one of them is its dodgy scope.

I'm currently writing a Flash Openstreetmap editor. Earlier this evening I had a brainstorm and figured a whole lot of funky stuff could happen if I were to use Flash Remoting to populate the objects server-side. As my natural environment is self-modifying Z80 code and page-aligned lookup tables this is all a bit scary.

The Flash Remoting server bit was fairly easy due to a really lovely PHP script here. (This means that my project now contains Perl, Ruby, PHP and ActionScript, as well as a load of SQL, but no matter.)

The problem, however, comes when you try and accept the data back into your ActionScript. For this you're meant to use onResult, something like this:

OSMWay.prototype.load=function(wayid) {
responder = function() {};
responder.onResult = function(result) {
this.path=result;
trace "Woohoo, I just loaded "+result+" into the object";
};
remote.call('getway',responder,wayid);
};

which should all make loads of sense.

Unfortunately, ActionScript takes this to refer to responder, which exists somewhere out in wacko object space rather than as a child of the nice object I'm trying to populate. So I can't actually find any way of addressing my object. Gah.

There are about eight billion solutions out there, almost all of which tell you to use something called mx.utils.Delegate. Unfortunately this is strictly ActionScript 2.0 only. Ming doesn't do ActionScript 2.0, and after a very fruitless hour-and-a-half trying to get some code to compile with MTASC, I'm inclined to agree with it.

Fortunately, a solution came out of nowhere, like it generally tends to at some stupid time in the morning.

Send the object name (this._name) as an extra parameter to the Remoting server. Get your server to send it back with the rest of the reply. You can then use this to create an absolute path for addressing the object. Like so:

OSMWay.prototype.load=function(wayid) {
responder = function() { };
responder.onResult = function(result) {
_root[result[0]].path=result[1];
};
remote.call('getway',responder,this._name,wayid);
};

Now I can go to sleep.

Comments

Your comment about your natural programming environment sounds like somebody declaring, "As somebody who earns his living by juggles rusty chainsaws while riding a unicycle and wearing a blindfold. I find this whole lion taming business depply terrifying."

Posted by Duncan MacGregor on 7.9.06 11:45

Hi Richard

I've know many Flash developers who've had success with MTASC. Going to Actionscript 2.0 is definitely worth it, with native OO support its much cleaner to code in.

I rewrote worldKit in 2.0, in preperation of moving from the Flash IDE to MTASC. Going to get it working with MTASC in the next couple weeks. I'll let you know how it goes, and give you any pointers if you want to move that way.

Agree that some kind of server side processing is necessary, since loading and parsing XML in the Flash Player is really slow (though apparently this has been sped up considerably in FP 9). What are your thoughts on the API producing and returning a SWF with objects, rather than setting up a seperate Flash Remoting interface?

Posted by Mikel Maron on 11.9.06 14:02

Add a comment

Your name:

E-mail address: 

Comment:

your comment. (E-mail addresses will not be visible, but a server-based mail link will be provided. To guard against spam, no comments which include 'http' or 'www' will be published.)