Why Dojo needs a client side MVC framework

Firstly a big thanks to Kenton Smeltzer Chief Web 2.0 Architect and Senior Director of Technology at Marriott Vacation Club International MVCI for helping shape and craft these ideas and bringing this whole vision together.

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.

dojoriaframework

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.

Advertisements

4 Comments Add yours

  1. Oyvind says:

    Hi Matt,

    Thanks for the interesting article. Will this framework, Kuba, become publicly available at some point?

  2. Sean DF says:

    Hi Matt,

    I found this blog entry and your post on UI Design Patterns very interesting and pertinent.

    I am wondering if you still use the same architecture today (a little over a year later):

    DojoJSON Rest StoreJSONJAX-RSJPA-EJB3

    and whether the Dojo team are now working on an MVC framework that you know of?

    Sean

    1. mattperrins says:

      I spoke with Dylan from Sitepen about Dojo MVC, the issue is getting consensus from the open community, mean while we inside Software Services For WebSphere have designed and built Kuba an MVC framework we use with dojo on our projects 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s