www.not404.com

I've been playing with the Dojo Toolkit (Release 1.0.2) for the past few weeks, and have made great progress in patching the Ruby on Rails core (2.0.2) to produce compatible data.  (side rant:  Hacking up Rails Core code is no fun at all -- not only do you have to find the issue and fix it, but you have to decide if your fix is specific to your own needs, or "General Purpose" enough for submission to the Rails Core team.)

*Grumble*  Anyways.  Despite not submitting patches, I've finally got a patched Rails Backend that works quite nicely with Dojo Toolkit.  In fact, it's kind of awesome to see the kinds of simple applications I can build with just plain old Dojo Toolkit, along with static JSON data islands.  And using the complete Dojo Toolkit definitely rocks my world much better than the (limited and outdated?) Dojo Toolbocks rails plugin.

The  dojo.data.ItemFileReadStore or dojox.data.QueryReadStore are perfectly fine for the small stuff (simple Tree Views, or for backing Data Grids), but I quickly ran into problems when I tried to do more complex Schemas -- particularly when I wanted to represent Schema Associations.

JSON: Type Information is Lost in Translation?!
As part of my system design, I am standardizing on exchanging JSON over the wire. There are compelling reasons to use JSON:  the declaration markup is much more compact, and it's wayyy faster and easier for JavaScript Engines to deserialize JSON into ready-to-use objects.

The downside to using JSON, though, is that you don't get type information in the output results. At least not by default.  That kind of sucks, because I'd like to represent Nested Associations in the output data. For example, let's look at the standard Dojo Continents/Countries example in XML:

<country>
  <area nil="true"/>
  <id type="integer">1</id>
  <name>Africa</name>
  <ntype>Continent</ntype>
  <population nil="true"/>
  <timezone nil="true"/>
  <children type="array">
    <child type="Country"> contents of child 1 XML trimmed by lalee </child>
    <child type="Country"> contents of child 2 XML trimmed by lalee </child>
  </children>
</country>

and the same data, in JSON:

  {  
  "name": "Africa", 
  "ntype": "Continent", 
  "timezone": null, 
  "id": 1, 
  "area": null, 
  "population": null, 
  "children": [{contents of child 1 JSON trimmed by lalee},{contents of child 2 JSON trimmed by lalee}] 
  }

Everyone seems to shrug this off as the price to pay for using a simplistic protocol. Umm.. no. There's no good reason why Schema Associations and Type Information (of associated records) can't be maintained and honored. In fact, a lot of what I plan to do with Django/Merb/Rails (backend) + Dojo Toolkit (frontend) absolutely depend on proper maintenance of Schema Associations.

If I were writing a Blog Server, I'd want to represent a Schema consisting of Posts, Comments, and Users. That way, a Post that is deep-fetched from a DataStore can provide data for the Post, displayed in the main area, as well as nested Comments, displayed in a DataGrid.

There's no "position" Attribute, Either
Something that Bill (a Dojo Developer) has been thinking about is the Drag n' Drop support of dijit.Tree.  Yes, drag and drop of TreeNodes will be a problem with a Server-Persisted DataStore - you probably need a position attribute that is persisted on the server .  The only way to avoid that is if the client and server always exchange data with Nested Attributes in sequential order.  That extra sorting requirement just seems like extra overhead.  I'd much rather exchange and alter a position attribute, and have the client side sort the data if necessary.

Why Build a Dojo DataStore from Scratch?
Yes, I did look at the list of available data stores. I certainly did examine the source code. I even tried deriving from the stock datastores, and overriding a few key methods. But no, I'm really not thrilled with how the stock DataStores are written.  Not because they're sloppy code, but because they just don't go far enough for what I want to do.

Remember, I really want to maintain Schema Associations (Nested or Related Records), and I also want to specify an attribute to identify the nested item's position.  (i.e. acts_as_list in Rails).  From the looks of the materials posted on the Dojo Toolkit website, it seems they were planning to create a dojo.data.api.Schema that would be useful, but the proposal was never ratified.  Rats!

Thus, with no DataStore that can handle Schema Associations (and especially Nested Associations done “The Rails RESTful Way”), I have no choice but to move ahead and write something on my own.  Blecch, this is turning out to be a LOT more effort than I had hoped for, but dammit, I really need this for the kinds of Rails Projects I want to do.

On a positive note, though... I'll probably become one hell of a Dojo Toolkit Coder at the end of this journey.  Am I on crack?  Or am I right on the money here?  Considering how very few posts I've seen expressing interest in using Rails with Dojo Toolkit, I'm left wondering if this Data Store project could possibly be useful to anyone else.