views:

36

answers:

3

I'm wondering what would be considered best practise for this. It's fairly inconsequential but I'm interested in peoples opinions.

We have two classes - TitleBar and TemplateMain. TitleBar is a bar at the top of the screen that displays the project title and several buttons (settings, print, fullscreen, etc) that the TemplateMain will need to listen to in order to run the relevant functions. At the moment, the Template listens for the click mouseevent and then uses a switch statement to get the initial target of the event, eg:

protected function onTitleBarClick(e:MouseEvent):void {
  switch (e.target){
    case (titleBar.settingsButton):
            addSettings();
            break;

     //     etc..

    }
}

Would there be any advantage or is it desirable to port this into a custom event system, either extending the native Event class or maybe even as3signals so that the titlebar itself has the click listener and then dispatches an event that TemplateMain picks up and then acts accordingly? One negative of this I can see is that, along with mouse click listener, I'd end up with another six listeners for the custom events.

Like I said, maybe it doesn't matter but I'd like to know how others handle this very common situation.

A: 

You can use a custom event or a regular event, but you don't really need six different listeners. Just cast the event argument to something to generic, then test for the "type" of the event. For example:

protected function onTitleBarClick(event:Event = null) : void {
  if (event is MouseEvent && event.type is MouseEvent.CLICK) {
    if (event.target is titleBar.settingsButton) {
      // statements
    }
    if (event.target is titleBar.someOtherButton) {
      // statements
    }
  }
  if (event is MyCustomChangeEvent && event.type is MyCustomChangeEvent.SOME_TYPE) {
     // statements, etc.
  }
}

Usually, however, it's better to break up your handlers and not try to have one omnibus handler.

Robusto
not sure of the purpose of mixing both solutions there..
dr_tchock
+1  A: 

I would recommend taking the simple and straightforward route of attaching the TemplateMain handlers to the individual buttons directly. If you don't want to create a tight relationship between the two, then use a separate broker or something to register the event handlers.

class TemplateMain {
  function addSettings(...) { }
  function doSomethingElse(...) { }
  function doAnotherThing(...) { }
}

class Broker {
  function registerHandler() {
    titleBar.settingsButton.addEventHandler("click", templateMain.addSettings);
    titleBar.somethingElseButton.addEventHandler("click", templateMain.doSomethingElse);      
    titleBar.anotherThingButton.addEventHandler("click", templateMain.doAnotherThing);
  }
}
Sam
Why would you recommend that? I thought it was better to minimise the amount of event listeners hence my current approach.
dr_tchock
@dr_tchock, I've seen people do what you're doing, but it's not good. It adds extra code that has to be run every time an event is triggered and is totally unnecessary. Separate handlers is also easier to understand and maintain--each small function does just one thing. In the old-old-old days of Flash it was very common to use a single handler for everything because Flash didn't support closures, but even that was solved by ActionScript-generated closure classes in the Flash MX 2004 days.
Sam
A: 

I personally prefer to stay as close as possible to the "black box" principle where one component needs to know as little as possible from another component.

I would go for defining the events in the TitleBar. When the TemplateMain receives an event , it doesn't have to know where the event comes from , just what it is and how to react to it.

This gives you a couple of options, you can use a dispatcher object , or the TitleBar itself can be the dispatcher, although I always prefer when components are loosely coupled.

On the event listening end, to use a single handler or many functions would depend on the content of your functions really. i would go for clarity & legibility. I don't see the point of creating a function for a one liner, in such case I would favor the switch statement.

As for creating a number of listeners, I don't see this as a problem , it allows you to easily remove one or the other depending on the function's life.

PatrickS