Events - Part 7 (The Final Chapter)

This will be my final write up on Events (at least I hope so!). I've checked in the code and am content to let it rest for v3. After I post this, I will start updating the related docs. The classes involved are now:

• Event - This class is probably the most obvious. It is the class that is the base for all event description objects. These objects are created for each event and contain the details related to that event. Other than the data specific to the event type, all events have a consume method. This method can be called on an Event object to indicate that no further propogation or bubbling should be performed.
  
  NOTE: it is actually the presence of a consume method that duck types an object as an Event Object.


• EventSource - This class is analagous to the Observable class in ExtJS. This is the base class for objects that fire events. If deriving from EventSource is not possible, the mixinEventSource method can be used to bolt on these features to any class. The most important methods on an EventSource are on and fireEvent.


• EventHandler - This class is a base class for destroyable objects that need to also disconnect from event subscriptions. As with EventSource, if this base class cannot be used, the mixinEventHandler method can bolt on the appropriate functionality. The only method provided is mon. This works exactly like on except that it is called on the EventHandler object and the EventSource object is the first parameter. This approach was copied from ExtJS (those folks are clever).


• EventModel - This is very much a behind the scenes kind of thing. This is the class that implements the mechanics of connecting event subscribers to the event firing mechanism. The EventSource.on method does a lot of higher-level work, but then calls EventModel.subscribe to connect a method to an event. Similarly, the EventSource.fireEvent method calls EventModel.create and EventModel.fire. The EventModel then is responsible for the following:
  
  
  • Connecting a method to (and disconnecting a method from) a named event on a source object.
    
  • Creating event objects given parameters.
    
  • Firing an event object (including bubbling).

This division of labor allows EventSource to be connected to the basic EventModel or an implementation of the DOM event model. I've sketched out how that would look in domevents.js, but am not worried about implementing and testing it or anything. In fact, the domevents.js file is not including in any of the build targets - it is purely proof of concept.

This accomplished the design goals of making an event subscription interface that would apply to both types of events and even reuses a good bit of the higher-level logic required. When the docs are posted I will explain in more detail how all the pieces are used. The good news is that it is very similar to ExtJS. If you are curious, the code comments already document all this. Perhaps one day I'll figure out a good solution to javadoc-like extraction of comments from JavaScript...

P.S. Merry Christmas!