May 12, 2012

Event notification pattern in Javascript

The event notification pattern is widely used in Model-View-Controller based applications but is also applicable in other situations. The pattern allows unrelated objects to communicate information without having any knowledge about each others functionality. The pattern obeys the law of Demeter, also known as the principle of least knowledge. Sensible use of the pattern helps developers avoid a lot of messy code.

The impementation I wrote has the following functions:
Notifier.instance()
Returns the singleton notifier instance. The notifier instance provides methods allowing objects to post notifications and register or unregister for the receipt of notifications.

The instance has the following methods:
registerObserver(anObserver, msg, aMethod)
  msg:        the messages the observer wants to receive.
  anObserver: the object that wants to observe.
  aMethod:    the function to invoke on the observer upon
              receiving the given message. The function is
              invoked with two arguments, the message (usually
              a string) and a notification object:
              {sender: aSender, userInfo: theUserInfo}. aSender
              and theUserInfo being the arguments given in the
              call to postNotification.

unregisterObserver(anObserver[, msg])
  anObserver: the observing object.
  msg:        the message the observer previously registered
              for. If msg is undefined the observer will be
              unregistered for any message it was registered.

postNotification(msg[, userParams])
  msg:        the message
  userParams: additional information possibly accompanying
              the message.

Now imagine having a user-interface element on a webpage. Let's say a delete button the user clicks when he wants to delete the currently selected record on display. Ideally the button should not be bothered with details on how to remove the record from the database, nor how to remove the visual representation of the record. It's sole responsibility is to inform others it was clicked. Here's an example of a delete button using the event notification pattern:
<INPUT TYPE=BUTTON
onclick="Notifier.instance().postNotification('Delete');" 
VALUE="delete">
If the button is clicked it performs its sole duty: notifying others it was clicked.

We'll write a controller class and make an instance of that class responsible for keeping track of the selected record and removing the visual representation when it receives a notification to do so. Keeping track of selection is simple. We display a selection of records in a table and supply a onclick attribute for each row in the table:
<tr id="4" onclick="Notifier.instance().postNotification('Select', this.id);">

We could have yet another class (a model class) being responsible for performing the magic of having the server-side application remove the record from the database.

Let's have a peek at the ViewController responsible for removing the visual representation of the record:
This code clearly shows the beauty of the event notification pattern. The tablerows have no knowledge of the controllers and the controllers have no knowledge of the user-interface elements.

I implemented this pattern on a project for one of my customers. So unfortunately I feel not at liberty to disclose the source-code. Thus I'll do the next best thing and publish the boilerplate for the Notifier:
I hope the boilerplate gives a good hint at how to implement this pattern. Remember, programming should be fun and in no way should lead to an uncoordinated mess of statements. This pattern is useful in many situations and will help you avoid messy code where objects unwillingly have knowledge of the functionality of a myriad of other objects.

Having problems implementing this pattern in whatever language? Give me a call at janwillem.luiten at gmail . com!