Two Reasons EventDispatcher is neato-cheato

7 Replies to “Two Reasons EventDispatcher is neato-cheato”

1. EventDispatcher is nice.. but GDispatcher r0xx.

   http://mxblogspace.journurl.com/users/metalogic/index.cfm?mode=article&entry=1047

2. Thanks to both!

   p.s. Is the code — event_obj.target + ” from: ” + event_obj.target — correct?

3. Richard, no, I meant event_obj.type for the first one, sorry, twas late.

4. Maybe it’s just me, but I don’t see the value in getting type as a property, if you HAVE to specify the event AND the name of the handler HAS to be the name of the event … seems very redundant.

   I do see the value in having this when you want to use handleEvent – this way you need to know the type. But otherwise, it’s a wasted property, to me. Maybe I’m wrong. Can anyone explain its value outside of handleEvent?

   Btw, you could always pass an object as a parameter ;)

   I’ve developed a class for a project that I’m working on that actually uses the best of both worlds (in my view, anyhow). I don’t want to post a full description here, as this is Jesse’s blog, not mine ;). When I get my blog up, I’ll make sure to revisit this. Unless Jesse, you don’t mind me throwing up a description?

   Derek

5. Post it baby; I’ll reconstitute into a new blog entry if you wish.

   The type parameter merely tells the dispathEvent method in EventDispatcher which method to actually call as an event. It is redundant, and you’ll almost never use it like I showed. The only time this is really needed beyond EventDispatcher’s internals is if you are actually forwarding the event somewhere else via a wrapper/proxy type class, and need to confirm what even the event object is actually coming from.

   …again, this is rare as far as I can see.

6. Thanks Jesse – I like to blab! :) I don’t think it constitutes a separate blog (maybe in length).

   It looks similar to GDispatcher in the addListener parameters, but the order is a little different:
   my_mc.addListener(listener_obj [,eventName] [,functionName]);
   The functionName parameter is optional, and if left out, the eventName will be used. The eventName is also optional, and if left out the object will receive all events. Plus you can provide a functionName and make eventName null so the object receives all events, but can still have one method. Otherwise the name of the event will be used.

   There is an advantage to placing the listener object first in the list… it is always required. Looking into the EventDispatcher.as code, I notice they use the event as part of an object name that holds a list of listener – which would be why the event is first, and required.

   Here is where this class really differs from the other event dispatchers: the arguments returned. All of the arguments are returned as separate args, just like AsBroadcaster, _unless_ you are using the handleEvent method, which is always called.

   handleEvent receives one argument, which is an object, just like the new dispatchers – with one exception: all arguments passed are kept in an array called args. Why? To avoid collisions with properties of the object that belong to the dispatcher – so you don’t, potentially, have to change anything if the code for the dispatcher changes for any reason.

   Also, the addListener and removeListener methods will return true/false indicating whether the object is the first listener for that event and if it is the last listener for that event, respectively (required for some functionality in my project).

   I know this probably sounds like I’m all over the place, but bare with me. To me EventDispatcher is like a bazooka – nice and powerful, but sometimes way overkill.

   Here is some sample code:
   // :: Add button1 as a broadcaster at some point.
   NCBroadcaster.initialize(button1);

   my_obj.press = function ()
   {
   // :: arguments are what you expect from the object that caused the event.
   }
   button1.addListener(my_obj,’press’);

   Looks a little like addEventListener.

   OR

   my_obj.onPress = function ()
   {
   // :: arguments are what you expect from the object that caused the event.
   }
   button1.addListener(my_obj,’press’,’onPress’);

   OR

   my_obj.handleEvent = function (event_obj)
   {
   // :: event_obj has:
   // :: .event (name of event)
   // :: .target (object that caused the event)
   // :: .args (an array of arguments passed by the sending object)
   }
   button1.addListener(my_obj);

   OR

   my_obj.myEventHandler = function (event_obj)
   {
   // :: event_obj has:
   // :: .event (name of event)
   // :: .target (object that caused the event)
   // :: .args (an array of arguments passed by the sending object)
   }
   button1.addListener(my_obj,null,’myEventHandler’);

   Also, this class uses objects rather than arrays for the listener, so it’s faster … well, theorectically. I haven’t pit one against the other, yet.

   My reasoning for this direction is to address the uses for different scenarios, rather than force one method for all. This way you can take the bat to some cases, and whip out the bazooka when needed.

   Does that make sense? Any criticism appreciated. I can’t post the code yet (project still in the works), but I should be able to soon. I know it’s hard to comment on invisible code :) but any comments on the process would be great.

   Thanks,

   Derek

7. I’ve written an StEventDispatcher in AS1. Not sure how it compares performance wise to the others. It has several methods a lot of people won’t use that add to its size, but its constructed so they can be removed easily.

   It’s available free on my website, Macromedia’s Flash Exchange and flashcomponents.net

   http://www.shocktime.com
   http://www.macromedia.com/cfusion/exchange/index.cfm?view=sn110
   http://www.flashcomponents.net

   I have had a tone of downloads but almost zero feedback, so please take a look. (the code’s on my site.

Comments are closed.