I have been using the Dojo Store, Dojo Grid> and Dojox Wires a lot recently to build RIA applications that consume RESTful Services that I create in Project Zero. Since REST focuses on exposing resources, it puts some burden on maintaining flow on the clients. Model View Controller in my mind is crucial in Ajax applications. To reduce some chattiness, Ajax applications deal with data locally, and certain UI events trigger saving local data to the server. In essence, the Ajax applications that deal with local data now need to manage 2 resources, a local one inside the browser and a set of remote resources, and has to do so without the benefit of a transaction manager.

Applications have to worry about keeping the state of the local data clean, as well as deal with server data. This makes the role of a Controller in Ajax applications very important. An Ajax controller needs to: ** Respond to UI events* Synchronize Data between Local Model and Remote Model (RESTful Services represented as URL's)* Respond to Server events (Ajax responses or COMEt patterns)* Update View (or at least trigger the updating of a widget, or trigger a refresh of a smart widget). * Error Handling for all the scenarios above.

It seems that the Controller logic is where I use JavaScript the heaviest. Lately I have found the Dojox Wires really helps reduce the amount of JS that I write, so I am using it more and more inside my controller logic. It does not completely eliminate JS, but it gives my controller some structure. I previously blogged about Dojox Wires. I find myself repeating the same patterns again and again. The architecture looks like the figure below.

I may be looking to use JET Transformations to generate these type of clients from existing RESTful Resources.

I have had some interesting experiences with the Dojo Grid and the Dojo ItemWriteStore. A Dojo Grid can be populated from a Store. For a while, when I updated the data in the grid, the Dojo Store was not being updated. I had populated the Grid programmatically with code like this:

I was doing it programmaticly because I had to first wrap the RESTful Data into Store format (I recently discovered wires helps here too). My friend and coworker Jared Jurkiewicz then told me that the DojoData Object for the Grid needed to receive the Store at construction time, or else it would think the Store was read only. So if you want changes to the Grid to propagate to the Dojo Store, you need to create the Grid Model by passing the Store in its constructor as shown below.

This is actually a scaled down example of the Incentive Finder component within the website called energycommons.com. Currently this site is in Beta and we are making many more enhancements to improve the usability and function.

Many have commented on Oracle buying BEA out there in the blogging community. One thing I am very interested in seeing is which persistence mechanism is supported if they choose one. Most likely, we will see Oracle pushing BEA's App Server. TopLink has had a long history as a persistence provider and supports JPA. But BEA's App Server is based on OpenJPA (more specifically the Kodo product they purchased from SolarMetric.) IBM also built its JPA provider(available via the EJB 3 Feature Pack for WebSphere) on top of OpenJPA. It should be interesting to see which way Oracle/BEA goes with in persistence.

** API's for exposing Java EE applications using JSON , JSON-RPC , and ATOM .* An Ajax Proxy which allows you to deal with cross domain security issues.* Ajax Messaging Bridge for extending your Messaging based Bus to the browser. This can be used to support COMet patterns.* Ajax Development support, which includes the Dojo Toolkit and some more widgets for Dojo that we provide.