We recently took on development for a client interface using the ExtJS framework. This was our first time working with the framework and, overall, we were really impressed by its flexibility.
One of the challenges we had was the fact that, out of the box, ExtJS expects to send and receive data in a very specific format. Since our customer had an API intended to serve multiple different clients this wasn't practical. The text book solution to this is to implement a JsonReader, which allows complex objects to be serialized, converted, mapped, etc. While a (very) handy feature of the framework, this wasn't ideal for a few reasons:
- Repetitive Code: For most forms, we simply needed a 1:1 mapping. Using a JSON reader forced all fields to be manually mapped which seemed redundant and unnecessary. We really just needed a) the ability to specify an alternate root, and b) the ability to "flatten" complex objects (e.g., {data.address.zipcode}) into a bindable format (e.g., a record named "data.address.zipcode").
- DataWriter: It didn't address the write scenario, where the data needed to be translated back into its original format (note: in the new ExtJS 3.0 this can be addressed by a JsonWriter).
- RESTful API: We needed the submission method to be dependent upon the API, as opposed to Ext's presumed "POST" default. At the same time, we didn't want to have to wire up an Ext.Ajax.request() for each form since this was a universal assumption for the application.
This is where ExtJS really shines. To mitigate these issues, we wrote two custom actions - LoadJson and SubmitJson - which accept a "root" and "method" configuration variable. LoadJson flattens complex objects from the specified root into name/value records. SubmitJson repopulates it as a complex object, places it back into the source root and submits it via an Ajax.request() using the specified method.
For small applications this approach is probably more invasive than preferred. For a decent sized application with dozens of forms, however, this approach prevented a lot of repetitive code distributed across the application - and had some additional benefits in terms of centralizing error readers, error handling, etc later on.
tags: ExtJS, AJAX, REST, JSON, Action