Skip to main content

Connecting widgets in jMaki

Posted by carlavmott on October 23, 2007 at 11:56 AM PDT

Just how do I connect widgets to each other in jMaki? The publish/subscribe mechanism in jMaki is quite powerful and allows for peer to peer and anonymous communication. This blog talks about how to use the different styles of publish and subscribe in your code. I'll start with the anonymous case first and work my way to peer to peer connections.

As you know jMaki uses publish and subscribe (pub/sub) mechanism for the under lying communication between components. We call this form of communication anonymous because the publisher doesn't know who is listening and the subscriber really doesn't know who did the publishing.
It is useful when multiple components need the same notification and when we don't want to tie them closely together. All interested parties are notified sequentially of an event. You can see an implementation of this in one of my blogs Widgets talking to widgets.

Using topics to communicate across components can be a little confusing so I wanted to cover how jMaki widgets use topics. Almost all widgets that are included in jMaki subscribe to a topic or publish to a topic or both. The topic names are of the form /dojo/table or /lib name/widget name. We're in the process of updating the documentation files to include this information so that it is easily accessible. All topic names can be over written when specifying the widget in the page. This is done using the 'publish' and 'subscribe' attributes on the taglib or function call. Note that a widget can subscribe to multiple topics but publish to only one.

Getting an event, regardless of how you get it, is more meaningful if you also get data and know what to do with it. Therefore we have the ability to pass data along with the event and we have specified the format of the data for the various types of widgets. The data is passed in the payload of the event. The format of the data in the payload is described in detail in the data model pages.

But how does the receiving component know what to do with the data? When an event is published, the topic name includes a base name and a command. The base name is as described above and the command (indicating what action to perform) is appended to the base name. The command portion is the last string after the last '/' and the string before the last '/' is the base topic name. For example, the topic /dojo/table/select has a base topic name /dojo/table/ and command is select. All subscribers to the /dojo/table/select topic will be called and passed the payload which in this case, should identify the id of the item to be selected. If there are multiple table widgets on the same page subscribed to this topic all receive the notification.

Although pub/sub is anonymous you can use a naming convention when naming the topics so they correspond to a particular widget. For example, there can be three buttons on a page and you can use specific topics for each. Button 1 uses /button1, button 2 uses /button2 and so on. Next create a separate subscriber for each of the button topics. This, in affect, maps a button to a specific subscriber creating a little more closely coupled relationship.

Finally, there times when you really want to interact with a specific instance of a widget. There is a function in jMaki which will return the widget instance. Simply call jmaki.getWidget passing it the id of the widget. You can then call the public functions available from the widget. Below is the code showing how to set the id of a widget and how to get the widget instance.

Set the widget id:

   <a:widget name="dojo.editor" id="myeditor" value="Edit this" >

In my glue code I can get the widget instance and use that to get the contents of the widget.

       var editorId = jmaki.getWidget('myeditor');
       var content = editorId.getValue();

The publish and subscribe mechanism in jMaki is very powerful and allows widgets to talk to each other and other components. Defining the data and event models for the different widgets simplies and standardizes the interactions.