This content is archived. See latest version here

EPiServer makes use of the Dojo publish and subscribe messaging system for passing events or notifications to different components in the user interface. The Dojo toolkit provides functionality to facilitate this kind of communication, since 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.

Implementing client-side messaging

Publish/subscribe is a well known pattern for promoting decoupled messaging and communication between independent application building blocks. The decoupling that we achieve with publish and subscribe is a result of using the central messaging hub in Dojo and publishing and subscribing on specific topics rather than on specific objects.

For example, imagine in edit mode I want to create a widget to display some statistics about the current page from Google Analytics or similar. My widget needs to know when the page changes in order to update what it is displaying to reflect the current page. I do not know what widgets are on the page currently or which can cause the context to change, so I cannot listen to events on any particular objects. However we know there is a message with the /epi/cms/contextchanged topic that gets published on any context change. So the widget can subscribe to that topic in order to update its context.

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

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

This code will now be invoked any time another component publishes a message with the same topic.

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

As you can see this makes it very easy to simply add new modules to the system and listen to existing events without changing any existing code. It also means many objects can listen to the events of one particular object without the need for that object to keep track of who is listening to it, as you might in a normal observable pattern.

Public topics

Component Description
/epi/cms/requestcontextchange Requests the application to try to change the context to a new one by passing it some information about the new context, pageLink for example, as well as a reference to the object requesting the change.
/epi/cms/contextchanged Occurs when the current context has been changed. Returns the new context along with a reference to the object which 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 which originally requested the change and the parameters passed with the context change request.

Last updated: Feb 23, 2015