Skip to main content

jMaki data models formally specified

Posted by carlavmott on July 30, 2007 at 10:32 PM PDT

The jMaki data models have been formally specified and as of last week, build .9.6 implements all specifications. The data model pages include the formal specification of the data expected by the widgets. They also include information about the event types and payloads published by the widgets as well as the event types and payloads expected by the widget subscribers. You will find lots of examples to help you get started.

When you look at the pages you will see that the data models are described using BNF. I like this format because it specifies what is legal as well as what is not legal. The data models are defined for the various types of widgets such as menus, trees. tables, tabbed views etc. The data models are consistent across the widgets regardless of the underlying toolkits. The jMaki widget wrappers convert the data from the jMaki data models to the model the underlying toolkits expects. This way you can switch between the toolkits without having to change the data format. Also the widget wrappers include publishers and subscribers so that dynamic widget to widget communication is greatly simplified. I'll talk more about the publishers and subscribers later in this blog.

In all cases you will see a set of properties that are common across the models. I'll go over some of these properties but see the main model page for a complete description.

  • id - id of the item such as a tab, table row or tree node. You use this property to identify that item.
  • label - the label or title of a tab, column, tree node or menu item. In the past we were not consistent across the data models but now have settled on label as the identifier.
  • href - indicates that the following string is a url and that when clicked we navigate to that url.
  • include- indicates that the following string is a url that we include in a container in the page.
    • action - indicates that the following object is used to communicate some action in most cases to other widgets.
    • topic this string resets the topic name for this element only
    • message can be a string (usually a url) or an object which contains data passed to another widget
  • targetId - the id of the element the action is to affect. This was set using the id property above. targetId is used regardless of whether the element is a node, row, tab etc.

    We tried to be consistent across the models so that users would learn one model and most if not all the information would carry over to the other models.

    Something that is new to the models is the action property. The action property is a declarative way of associating widget behavior. This is extremely powerful for simple operations because no JavaScript code is required to affect another widget. As a result of adding actions we found that we needed to describe the event model as well. Widget to widget communication is simplified because now the widgets also subscribe to various topics out of the box. They also include handlers for those topics. This means that you can publish to a topic which a widget is subscribed to, passing along the correct data and you can affect the behavior of that widget. This works much the same way as I described in my previous blog jMaki - widgets talking to widgets only you pass all the needed information as an action. See Greg's blog for a example on how to use actions .

    As I mentioned above the widgets now subscribe to topics and handle certain events. The underlying mechanism for communication is still publish/subscribe (see the article 'A practical guide to jMaki events' for details on events in jMaki). The main idea is that widgets now subscribe to one or more topics such as '/yahoo/tabbedview/select'. There is a handler in the widget code which parses the message or payload and performs some action based on the topic name and the payload received. Consider the case of the tabbed view. The widget subscribes to the topic 'select' and contains a handler which expects the id of the tab which should be selected. By simply publishing a message to that topic containing the tab id to be selected you can affect which tab is visible on the page. What all can you do? What are the subscribers and what data is required? All these questions are answered in the model pages. You will find the list of events that are handled as well as the payload expected for each type of event.

    Related Topics >>