3 Replies Latest reply on Feb 14, 2009 7:25 AM by Bart Alcorn

    Proper naming conventions for events?

    Handycam Level 1
      I am finally starting to understand custom events, but I admit that despite what I have read I am confused at the proper way to name events and their parts, or when multiple events can be part of the same class.

      For example, attached is an even I created for a quiz that is dispatched when the user makes a choice in my choice mxml component.

      The dispatch is like this:
      this.dispatchEvent(new ChoiceMade(ChoiceMade.CHOICE_MADE));

      It seems a bit dumb to have ChoiceMade.CHOICE_MADE. Is there a better naming convention?

      Also, many of the built-in events have "sub-events" such as MouseEvent having MOUSE_CLICK, MOUSE_OVER, etc. How do I set it up if I want to have this class able to dispatch more than 1 event, such as CHOICE_MADE, WRONG_ANSWER, etc?
        • 1. Re: Proper naming conventions for events?
          Bart Alcorn
          Personally, I would have named the class ChoiceEvent rather than ChoiceMade. Then your event would be ChoiceEvent.CHOICE_MADE.

          Since the constants are part of the class, repeating 'CHOICE' as part of the constant is redundant and adds little value.

          For example, there is no ambiguity in :
          ChoiceEvent.MADE
          ChoiceEvent.AFFIRMATIVE
          ChoiceEvent.NEGATIVE
          ChoiceEvent.CANCELED
          ChoiceEvent.WRONG_ANSWER
          etc.
          ~ Bart

          • 2. Proper naming conventions for events?
            Handycam Level 1
            Very good point Bart, that's what I was looking for.

            So I would just add constants for the other events, as in:
            public static const MADE:String = "choiceMade";
            public static const NEGATIVE:String = "choiceNegative";
            • 3. Re: Proper naming conventions for events?
              Bart Alcorn Level 1
              Yes... but. ( There's always a but! )

              You certainly can, and often times should, have Event constants for specific 'events'.

              But other times you should have a more generic 'transport' event. i.e. ChoiceEvent.MADE which as a custom event also accepts a parameter and passes it along. This way the event 'transports' some vital piece of info.

              See example code below.

              This custom event allows you to (optionally) pass the answer/choice made along with the event. You can then put your logic on either side of the event... either deciding the choice was right/wrong/other and dispatching a right/wrong/other event... or dispatching a MADE event, and including the answer in that event so that whomever is listening can do whatever they need to/with the answer.

              ~ Bart