jMaki data models formally specified
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.
- 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
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.
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.