Publish and subscribe messaging system

Optimizely Content Management System (CMS) uses the Dojo publish and subscribe messaging system for passing events or notifications to components in the user interface. The Dojo toolkit provides functionality to facilitate this kind of communication because Dojo promotes class declaration and modular development, and one of the main mechanisms for ensuring that modules remain decoupled is to use this publish and subscribe messaging system.

Implement client-side messaging

Publish or subscribe is a well-known pattern for promoting decoupled messaging and communication between independent application building blocks. The decoupling achieved with publish and subscribe results from using the central messaging hub in Dojo and publishing and subscribing on specific topics rather than on specific objects.

For example, suppose you want to create a widget to display statistics about the current page from Google Analytics. The widget needs to know when the page changes to update what it displays to reflect the current page. You do not know what widgets are on the page or which can cause the context to change, so you cannot monitor events on any particular objects. However, a message with the /epi/cms/contextchanged topic gets published on any context change, so the widget can subscribe to that topic to update its context.

postCreate: function () {
    this._contextChangedHandler = topic.subscribe('/epi/cms/contextchanged', this, this._onContextChange);
  },

  _onContextChange: function (context, caller) {
    // Widget will update itself using the new context.
  }

This code is invoked whenever another component publishes a message with the same topic.

topic.publish('/epi/cms/contextchanged', [context]);

You can add modules to the system and monitor existing events without changing existing code. Many objects can monitor the events of one particular object without needing that object to keep track of who is monitoring it, as you might in a normal observable pattern.

Public topics

• /epi/cms/requestcontextchange – Requests the application to try to change the context by passing it some information about the context, pageLink, for example, and a reference to the object requesting the change.
• /epi/cms/contextchanged – Occurs when the current context is changed. Returns the new context and a reference to the object that originally requested the change.
• /epi/cms/contextchangefailed – Occurs when a context change request has failed. Returns the current context along with a reference to the object that originally requested the change and the parameters passed with the context change request.