I hope over the next few weeks to start to document some of these key best practices so that others can benefit from them. The whole experience has been hard work but the results of what is being built is going to help others that are targeting modern HTML5 based web browsers.

The topics I am going to cover:

• Business Widget design and implement
• Model View Controller advances in use with Dojo and Web 2.0
• Web 2.0 Session State moving from page to page
• REST Catalogs and REST Signatures
• Maven Builds and Shrinksafe with Dojo and Eclipse
• Styling with CSS3

I think this will keep me busy for a for weeks and help me get some of this information out of my head and into a form that will help others.

The issue that was hurting this customer was it was taking up to 50 days from design to going into production for every screen. This was a lot of time for basically a simple CRUD (Create, Read, Update, Delete) pattern for the User Interface.

For the modern enterprise applications a variety of technologies are coming into play that are reducing the amount of boiler plate code we need to write to achieve these same steps. I am currently looking at the following list of technologies for my Web 2.0 JEE stack.

Dojo<->JSON Rest Store<->JSON<->JAX-RS<->JPA-EJB3

To assist in the use of this approach I still keep coming back to these User Interface Design patterns . They help me to think of what the User Interface is doing and how to map it into service calls to the server. With the server now turning into a true data server and frameworks like Dojo doing the heavy lifting for the User Interface it becomes very easy to map the asynchronous requests to these patterns.

Here are my initial list let me know if you can think of others.

Most task worker or business level user interfaces will use a combination of these types of patterns. They can also be used in combination for multi channel solutions where you keep the controller and model elements common across the channels.

The presentation link below shows more detail, here is an example for Master Detail pattern which I use a lot.

Intent:

–The master to detail pattern is often used within client facing applications. The requirement to retrieve a record of data and then display the detail associated with is very common in application design. This pattern can be easily mapped to a many-to-one relational schema used within a database design. The data can be displayed in a grid or table type control and when a selection is made on the table a more detailed form of data can be displayed.

Based On:

–This pattern is based on the Model View Controller pattern and Display Form, Validating Form, Update Form patterns.

Dictionary Entries:

–Key, Table, List Form, Retrieve, Object

Motivation:

–The requirement to search a list and then display more details of the items in that this is very common in user interface design. This pattern will allow a list of model objects to be presented in the Table List pattern and then when an item is selected it can be displayed in a Display Form pattern. As the user navigates through the list the form will update with the information.

You can find more in the PDF presentation.

Download full presentation

I have watched Microsoft effectively let Internet Explorer 6.0 stagnate and become the browser of choice in the enterprise. The issue is that it is not competitive or fit for purpose for all these new RIA solutions using OpenWeb and Ajax. I have watched as Adobe and Microsoft then expand their position of ubiquity to turn Flex into a full blown programming model and leverage the OS and Browser dominance to push Silverlight onto peoples desktops.

If customers start heading down the route of building full end to end solutions around these proprietary programming models and runtimes they are effetely walking away from the base principles of what the OpenWeb was created for.  So let me confess, I love pixels and sexy UI’s and Flex and Silverlight allow me to do some really cool stuff and I wish that the W3C would get their act together and work with the browser vendors to deliver the same flexibility through open standards but that is not going to happen soon.

So what can you do to manage this ? I have been thinking that at the moment there are some cool things that Flex/Silverlight do very well. Video, Interactive Updating, Charting, Modelling Diagram Editors etc.

There are some component standards starting to arrive, we have had JSR 168 for a while and this has been expanded to JSR286, We are starting to see iWidget spec start to deliver for the Mashup requirements. Within Desktop RCP with iView has enabled a layer of control to be added around content within tools and runtimes.

So if we start to think of our applications as true components brought together around component standards and allow the outer shell of an application to still be delivered by OpenWeb we can start to take advantange of Flex/Silverlight to fix some of the interesting Ui problems like Charting/Diagrams but keep them inside the box of a component. This will protect you for change in the future and still enable the User Experience you want to delivered.

If you let the full shell to be replaced then you are heading down a path that we moved away from in the 90′s lock into a set of Client Server style standards controlled by a single vendors and not open.

Next time you are building a solution have a think about breaking it into components and then using the right technology to delivery that component wether it be OpenWeb, Dojo, Ajax, Flex or Silverlight. If we support the component standards the Open Web will mature to compete head on with what Flex and Silverlight and you will not be stuck with a lot of code written to an out of favour web ui runtime.

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.

In the creation of modern Rich Internet Applications (RIAs) that follow the open web design principles, it is essential to enable developers to follow design patterns and best practices. Existing RIA frameworks, such as the Dojo Toolkit, have focused on solving problems around user experience through widgets and a common component model for widget composition, but there is a gap with respect to a simple, robust programming model that allows the consistent construction of RIA applications.

JEE technology faced a similar problem and it took a number of years after its initial release for developers to adopt the patterns and practices that would enable the development of scalable applications that could be maintained by enterprise development organizations.

Dojo is now at the same point it needs an RIA framework, that extends the Dojo Toolkit with a set of specific framework services, such as logging and page forwarding, state handling etc.

This RIA framework would follow some of the core principles for building robust flexible RIA applications. The following are the most important elements:

• The Dojo Toolkit is used as the underlying component model for widgets and other elements of the framework.
• Any new User Interface Widgets follow the clean Model View Control used by the dijit sub system of Dojo. This creates the separation of concerns needed to enable User Experience (Ux) designers to control the layout and look and feel of each page without needing to modify the functionality of widgets or pages.
• Logical segments of a page are broken into reusable Bijits Business Widgets that follow very similar principles as iWidgets in that they expose attributes and events and operate in a self contained way. ( more on this later)
• Each Logical Page is contained in a single HTML file. This file encapsulates all the elements required to manage the display and rendering of all the each widgets and to support the user interaction requirement for the page.
• A Controller pattern is used by each page to define a consistent interface between the layout of the page and the actions and behaviours of how the page will function.
• Pages use Stateless Services using URI, RESTful, and RPC invocation types.
• The Application server is used to deliver data feeds in the form of JSON, XML and ATOM. Most importantly, the application server will not be used for page rendering.

With the adoption of these guiding principles, together with Dojo’s out-of-the-box support of some of the higher level business requirements, this approach can offer a comprehensive Web 2.0 application development framework. And break the model of the server needing to generate the Ui and add flexibility to the Ux teams to change layout and page function without the pain managing JEE artifacts.

The following diagram outlines the major elements and the separation of concerns for such a Framework.

A Changing Paradigm: View and Controller on the browser

RIA applications will be packaged into two distinct elements. The first will be the RIA Runtime artifacts that form the User Interface of the applications and provide the user experience for each page. The second is the Application Server Runtime artifacts and configuration that is used to deliver the supporting data to the RIA tier and integrates the RIA application to the corporate business service tier.

Within a modern RIA application the View and Controller have moved from the server into the browser, they now leverage DHTML, DOM and JavaScript to achieve compelling and easy to use applications, and use the server as a source for model data that can asynchronously requested by the controller. With this change of behaviour the View and Controller parts of the application can be completely separated from the server. This means that they can be delivered by normal HTTP servers and no longer need to be embedded within a server programming model like JEE or ASP.NET. This also means that the View and Controller elements can be developed without a server and can be unit tested in isolation from the server infrastructure.

I believe that this is next step for Web 2.0 enterprise application development and finally moving away from server generated Ui’s using JSP, ASPs,JSF, etc etc will enable greater level of flexibility.

About a month ago I started to look at how to develop iWidgets for the IBM Mashup Center 1.1. I come from a J2EE WAR based programming background so was interested on how to configure my Eclipse based tooling to develop iWidget in the easiest way possible.

The following steps worked for me and allowed a very quick edit, save, publish, test cycle where I could edit the iWidget code and have it running in my browser in seconds. IMC 1.1 does support OSGi packaged iWidgets I will look into that next time.

Steps

When developing iWidgets for IBM Mashup Center (IMC), rather than repeatedly create and deploy new WAR files to IMC, it is possible to configure RSA/RAD 7.x such that the WAR files you are developing can be integrated with the IMC runtime from your workspace. This way, you can simply modify and test any changes by reloading the Lotus Mashups page in the browser. The following steps are required.

1. Create a WAS 6.1 server configuration for RSA/RAD that points at the WAS installation for IMC. If you installed IMC in the directory C:IMC for example, you will need to configure a runtime pointing at the directory C:IMCAppServer.
2. Use the RMI connector to make the server attachment, RSA/RAD should suggest the correct port for you to use for your connector e.g 2811. You should now be in a position to deploy assets from your workspace into the IMC WAS installation.
3. Create a Dynamic Web Project to contain your new iWidget together with an EAR in which to contain the resulting WAR. This is the container into which you put the contents of your widget together with the required deployment descriptors and so on.A description of what these look like can be found in the Lotus Mashups help pages together with the details of the iWidget programming guide. A simple iWidget WAR is attached to this page by way of an example.
4. Add the new EAR file to the server configuration you created earlier. It should now be available via the IMC WAS application server. You can test this by requesting the URL of the XML manifest for your iWidget using your browser — it should be visible through the newly deployed WAR file e.g.

   http://localhost:9082/CardReader/CardReader.xml

   where CardReader is the name of the WAR file.

5. Stop the IMC WAS instance using the RSA/RAD Servers controls.
6. With IMC stopped, we now need to edit the Catalog file so that the widget we are developing appears on one of the drop down menus in the Lotus Mashups editor page. This provides the linkage between the Lotus Mashups environment and our workspace widget. Look within your IMC installation for the file called catalog_admin.xml which if you have installed into C:IMC will be found in C:IMCmmpubliccat. Make a backup copy of this file.
7. Open the catalog_admin.xml file in WordPad. You will see it is organised into a hierarchy of categories and entries.
8. Copy an entry element and its contents and paste a copy within one of the category elements. Easiest option is simply to paste it below the entry that you just copied.
9. Modify the entry to contain a meaningful name, description and id and unique-name values on the entry element. No matter how strong the urge DO NOT REFORMAT THE XML. Preserve the original formatting.
10. Set the contents of the definition tag within the entry tag to the URI of your XML manifest. This links the menu item to your specific widget e.g.

    /CardReader/CardReader.xml

    to continue the above example.

11. Save the XML file.
12. Restart the IMC WAS runtime from RSA/RAD.
13. Load Lotus Mashups in your browser and login.
14. You may see a JavaScript dialog box containing the message “TypeError – 103e is null.” Simply press OK and then the reload button your browser. You should now see the Lotus Mashups Welcome Page as usual.
15. Press the Go to View button on the Welcome Page. You will see a set of tabs appear containing the categories you saw earlier in the catalog XML file.
16. Find the category into which you added your widget earlier. You should now be able to drag your widget from the menu onto the Lotus Mashups page.

Now, when you make changes to the widget in RSA/RAD, you can pick them up simply by reloading the Lotus Mashups page. When your widget is ready, you then deploy it by exporting the WAR file.