« OOP4AS2#6: Private members | Back to Main | [code] GDispatcher: Event swiss army knife. »

September 25, 2003

Ok, I have to post a bit of a retraction. While EventDispatcher is still a big improvement over previous event models, it's not quite as cool as I thought it was at 3am last night. Nothing ever looks quite as hot the morning after, does it?

The ability to subscribe functions or methods to events is made vastly less useful than I excitedly thought last night by the fact that the function will, of course, be executed within the scope of the object dispatching the event (duh). This means that really, this approach is only about as useful as a callback event handler (the functionality is virtually identical) - its occasionally handy for quick'n'dirty prototyping, but usually not good form.

Ahh... the murky clarity of 3am experimentation. Oh well, stay tuned, I hope to build out an extended version of the eventDispatcher that includes some nifty new tricks.

Posted @ 10:13 AM by Grant | TrackBack

check your previous blog entry on this subject. I posted what I wrote a while back. its the eventdispatcher, plus it allows you to define the object and method you wish to call if you want. it also lets you pass args (despite being less OOP in this manner)

Have you taken a look at Mach-II which morphed as an 'OO' framework from Fusebox? I do realize at this point most samples etc on written for CFMX.

ahh, morning Afters..:p

I think it's great because you can call public methods on the dispatcher from another object without explicitly calling the object. Does it break OO if you do this from a view that knows nothing of a model? Even if it does I think this functionality is great. AsBroadcaster couldn't do it.

How about using delegates?
I assume the use of delegates so I simply extended eventDispatcher to take two forms of addlistener, one with a delegate and the original form uses arguments.callee and builds a delegate on the fly. - most times, the target object is the same one adding a listener.