Quick Tip: Cairngorm Best Practice

Thursday, January 10th, 2008

When developing Flex applications in Adobe Cairngorm it is quite common to define all event constants as follows:

The problem with this design is that there is no way of guaranteeing the event type will not collide with an Event type in another package.

Now, I think it is only fair to say that in a good design there typically would not be two Events with the exact same name. However, when developing large scale Flex applications in which additional modules are added with each major release, not to mention the fact that there can be literally hundreds and hundreds of classes, the chances of creating an Event with the same name begins to increase.

As a best practice you should assign the Event type a value which is identical to the Event’s fully qualified class path. This will ensure there can never be a collision of Event types. An example can be seen in the following:

It’s always better to be safe than sorry.

{ 8 comments to read ... please submit one more! }

  1. Eric – you raise an interesting point. Although it has crossed my mind in the past, I admit I haven’t taken the time to come up with a solution. Your solution is intriguing, but it raises a question: What do you do when you define an event that supports multiple types, and therefore multiple type constants?

  2. That’s true Eric.

    I’ve always done it the way you initially wrote it (“LoginEvent”) – but for my next project I will definitively use the fully qualified class path. Smart 🙂

  3. That’s a great tip Eric, can save me a lot of debugging time.

  4. Hey Jim,

    The same applies in cases where an Event defines multiple Event types – you simply prefix the value of the constant with the fully qualified class path.

    For example:

  5. Hi Eric, i noticed your event class doest have the override public clone. isnt this necessary, i am fairly new to cairngorm and always define the override public function clone. what does the clone function do. sorry for my novice question

  6. Hey Yoofi,

    You are only required to override Event.clone if you need to re dispatch an Event so the values of each property of the new instance will be identical to that of the original instance.

    Additionally, if you are using modules and have a Cairngorm Command which is specific to a module and extends a base class which is defined in the main application, you will need to clone the Event so the base class can cast the Event to the required type. This is a tough one to debug so I advise everyone to keep it in mind!

    – Eric

  7. Interesting, an add-on to Yoofi’s post….

    would it hurt to always use override clone? i mean, will anyone be of any disadvantage if they always had an override clone. if i don’t need to re dispatch an Event Eric…and i have an override clone…would it be a bad idea? thanks


  8. Overriding clone if even if it is not really needed isn’t necessarily a bad thing. It really depends on your project, and if you feel that it is warranted then by all means implement clone.

{ 0 Pingbacks/Trackbacks }