Co-Author: Kenton Smeltzer Senior Director of Technology at MVCI and Web 2.0 Chief Architect.
Why do we need bijits? The Dojo toolkit has a perfectly good widget model defined in around _Widget and dijits. This statement is true and when used in conjunction with the wiring components can offer a flexible page construction model. The issue comes around the fact that this wiring and declaration is held in the page for all to see and lives alongside the page layout information. This can make the pages more complicated to the layout and Ux designers. The other issue is that these dijits do not become self contained self functioning components that can be easily dropped in other pages, you would have to move the widgets and the wiring rules from page to page and this is not creating a flexible component mechanism.
One of the specifications that is out in the market and is being sponsored by OpenAjax alliance is the iWidget specification. This spec is also a major part of the IBM Mashup Center 1.1 product. This mechanism for creating components that can be consumed by iWidget containers in web pages, desktops, side bars and directly in standard HTML. This specification has a lot of promise but at the moment requires a server component to read and analyze the iWidget configuration information and does not currently deliver a true client side only iWidget programming model. More detail of this specification can be found at the following link:
http://www-10.lotus.com/ldd/mashupswiki.nsf/dx/iwidget-spec-v1.0.pdf/$file/iwidget-spec-v1.0.pdf
So what are bijits? Bijits are an extension to the Dijit programming model to add all the features that an iWidget can support. Through this mechanism it will allow pages to be constructed from a combination of bijit components and then the page controller can wire them together to react to the bijits behaviour.
The key characteristics of a bijit are that it has an attribute space that a page controller can access to retrieve the defined attributes that are defined around the components. This is very useful for a form and complex multi dijit bijits. These attributes can be accesses using the getAtrribute and setAttribute methods.
The other key element is its support for events, these can be generated by the bijit and a page controller can connect to these events, and then make page logic decisions to pass data into other bijits. For example a user may select a date from a calendar bijit and this would generate the dateSelected event. This date value may then be set on a hotel availability bijit. By setting this value it would cause the availability bijit to request the availability for the hotels selection. This style of programming will enable the bijit to be completely self-contained from the page or context that it is placed within. This enables the component to be reused across many pages and have a defined programming interface.
Bijit Programming Model and RIA Framework
The RIA Framework contains a defined bijit programming model that will allow for segments of a page to be broken into self defined bijits with a defined attribute and event interface that can then be used by other developers build pages in an easy and flexible manner.
The bijit developer will extend a base Dojo class called “_Bijit” this in turn will be derived from a _Widget class. The bijit will contain a field name that will specify the name of the configuration file name that will be supplied in JSON format. The bijit implementation will then support a variety of programming interfaces that will support the usage of the configuration data within the bijit.
A key are to some bijits is the ability to access model data that is extended on top of the base data that the bijit may use for display. A good example of this is the Calendar bijit. You may have common services that can return a variety of Calendar data elements. The Enterprise Object model can be used by the bijit to map specific UI display or behaviour around the data and model that is returned.
The following explains the details for creating a bijit and how to use its core API’s.
Dojo Implementation
To create a bijit you declare a widget in the same way you would a normal Dijit but this time you would extend the “_Bijit” class from the RIA Framework.
dojo.provide("mvci.bijit.calendar.SimpleCalendar");
dojo.require("dojo.cldr.supplemental");
dojo.require("dojo.date");
dojo.require("dojo.date.locale");
dojo.declare(
"mvci.bijit.calendar.SimpleCalendar",
[mvci.dijit._Bijit],
{
templatePath : dojo.moduleUrl("mvci.bijit.calendar", "templates/Calendar.html"),
interfacePath : dojo.moduleUrl("mvci.bijit.calendar", "interface/Calendar.json")
The key difference is that as well as a templatePath that is used by the standard Dijit for containing the base HTML structure for the widget. You will need to define an interfacePath this interface reference will point to a static JSON structure that will be used by the bijit to define the various attributes and events that the bijit will support.
The interface configuration will need to be created inside a directory called interface that is at the same level as the bijit template directory.
The Bijit will automatically include the _Logging and _Context classes that are part of the core RIA Framework, _Resources and _Services can be added to the Bijit if it needs to access local resources and Services. _Forward is not included as this encouraged that only a Page Controller performs page forwarding techniques.
Template
The bijit must follow the standard Dijit implementation design when using Templates. This will require that the Bijit sets a templatePath member variable that will cause the Bijit to load its template code from a templates directly below the Bijit definition.
Life cycle
The bijit will follow the standard Dijit lifecycle. This is required to enable it to fit within the standard Dojo programming model. The life cycle for the RIA Framework is focused on supporting Page Controllers. Bijits need to behave just like standard Dojo widgets.
postCreate
To support this, the Bijit will need to implement the postCreate method. This is used to support the initialisation of the Bijit and the necessary elements, services and other elements that it will use. The attribute store for the bijit will be initialised by this time so it will be possible to access the attribute element values during this lifecycle.
Interface Configuration
The interface configuration follows the iWidget pattern exactly. This has been done to help future prove Bijits. At some point in time an iWidget / Dojo specification will arrive that will cover pure client side widget definitions. Once this has been done it will be very easy to migrate to this open implementation.
The following is an example of the interface configuration for a bijit:
{
// Define the Attributes for the Bijit
attributes : {
onItemSetChanged : "onItemSetChange",
private : "false",
names :
[
{ id : "date", value : "02/04/1968", readOnly : "true" },
{ id : "availability" , value : "", readOnly : "false" },
{ id : "current" , value : "", readOnly : "true" }
]
},
// Define inbound and outbound events
events :
[
{ id : "selectedDate" , payloadType : "any",
publish : "true" },
{ id : "date" , payloadType, "any",
handled : "true", onEvent : "dateChange"}
]
}
The structure of the configuration uses JSON so that the Bijit can easily load it and access it through its defined interface. It will also be cached.
Attributes
The configuration is broken into sections the first is the attributes list. The onItemSetChange value is the method inside the Bijit that will be called whenever a setAttribute method is invoked. This will allow specific logic or events to be triggered when ever data is set on the Bijit. If private variable is set to false then the attributes cannot be accessed from the bijit.
The Name variable array lists the names of the valid attributes that can be set or accesses. The attributes can have a default value and can have a variable set to determine if they are read only. The Bijit user will access the bijit through a set of setAttribute and getAttribute calls. These methods will manage the behavior based on the rules defined in this interface configuration file.
The Attribute store will be populated from the Page Context by the page controller. This will enable a bijit to be re-initialized when the page is refreshed.
getAttribute
The getAttribute method on the Bijit can be used to retrieve the value of a given attribute that is declared in the interface configuration. An exception will be returned if the attribute name does not match the name in the interface configuration.
API Specification
var value = bijit.getAttribute(“name”);
setAttribute
The setAttribute method on the Bijit can be used to store new values in the bijit. This will cause a method to be invoked inside the bijit that will allow it to manage the lifecycle of the data within it. For example if you set the date attribute this may update the current date displayed within the a calendar dijit.
API Specification
bijit.setAttribute(“name”,”Matthew Perrins”);
Events
To allow a bijit to exist within a page or within the context of an application it needs to generate and react to events. These events can be generated in a true decoupled way allowing the bijit to just focus on its use cases and business function. It can then deliver information through events to either the page or other bijits to create a consistent user experience. This also allows the bijit functionality to stand on its own and the bijit to be a re-useable as possible.
The events are defined in the events section of the interface configuration file. Two types of events can be defined. One is the inbound events or the subscription events. The second is the out-bound or publish events.
Publish Events
Publish events are generated by the bijit for other elements to subscribe to. This enables other elements like a page controller to react to a change in the information coming out of a bijit. A bijit developer will need to define the list of published events in the interface configuration. In the meta-data they will define the event id name, the payload type and if the event can support a publish call.
{id : “selectedDate” , payloadType : “any”, publish : “true” },
Inside the bijit implementation and out of sight from the bijit user the internal event system that is mapped to specific dijits or other events will need to perform a publishEvent API call.
Context
Inside the Bijit there will be an iContext member variable that will support the ability to publish values to event names. The following is an example of how the _currentDate value is published on the selectedDate topic for the bijit.
this.iContext.publishEvent(“selectedDate”, _currentDate);
Any subscribers to this event at the Page controller level will be notified of its change and then can react to the value and perform some level of page logic.
Subscribe Events
Subscribe events are the mechanism that defines how external page controllers or other bijits can publish data into the bijit. The example below shows a date event that will fire the dateChange method within the bijit.
{ id : “date” , payloadType, “any”, handled : “true”, onEvent : “dateChange”}
A page or bijit can bind themselves to this event mechanism by using the dojo.connect API. This will cause the bijit to trigger the internal method in the bijit.
dojo.connect(bijit,”date”,”02/04/1968”);
The setAttribute API call can also be used to trigger events
These are some of my ideas around extending Dojo dijits to become more like iWidgets we may get a true client side iWidget model in the future that would enable the same power that iWidgets is offering to mashups within the Dojo programming model. In the meantime I will use this approach.
