Proposal/Question: Object broker/dispatcher for alternative templates

[John Locke <..hidden..>]

First the disclaimer: I'm still not that familiar with the code base, so 
much of this may be in place already. I know there's been a lot of work 
done on separating out the presentation elements into a template. And I 
also know that there's a desire for some Ajax widgets and similar items 
to make the interface more usable.

The question is, what URL should the widget call to get data back to 
populate an auto-complete drop-down list?

Part I: handling multiple templates/output formats

This is an area I'd like to contribute to--we've been doing a lot of 
Ajax interface work, and are quite happy with the Dojo Toolkit. So my 
proposal is to set up some sort of object broker/dispatcher that lets a 
parameter in the request identify what template or format to return.

In another application, I've got a simple dispatcher that expects a 
module, an action, and a view. The module identifies what class to load, 
the action identifies which method to call, and the view identifies 
which template or document type to return.

I think it's useful to have this view parameter available to allow for 
experimentation in user interfaces. One view can specify an
application/xhtml+xml mime type, and have a lean mostly javascript-free 
implementation. Another view can specify text/html with heavy use of 
Javascript. Another view can be a simple JSON object returning data for 
a lookup.


The core development team can develop one set of templates for the 
lowest common denominator, whatever they choose that to be. And then 
other devs can essentially fork the front end, and provide competing 
implementations, with those that prove themselves out getting included 
as an option in the core? And users (or at least site admins) can choose 
which ones to use.



Part II: data requests

We'd like to start instrumenting the interfaces soon, using Dojo. What 
I'm going to need is a URL to query to get data back in JSON format. If 
someone can point us to a good place to implement this on the server 
side, we can work on this.

With Dojo, we can create custom stores to parse data in nearly any 
format. I've worked with CSV, XML, and JSON on the client side. JSON is 
usually the simplest, and has built-in stores to handle a particular 
format. So if the server side returned this format, it would be really 
easy to implement. Basically, for the existing Dojo stores, the server 
returns:
* a json string with a mime type of text/json
* the json string is an object with 3 properties: identifier, label, and 
items.
* items is an array of objects. Each array item is a result. The result 
object contains a property specified in the identifier, another 
specified in the label, and any other arbitrary set of data.
* For the built in QueryReadStore, the server should accept '*' as a 
multi-character wild card, and '?' as a single-character wild card.
* For large result sets, to support paging, the server should accept 
"start" and "count" parameters to define the page of results to load

I'd also suggest that we send back more than just a key/value pair for 
the JSON requests, especially for things like part numbers on sales 
orders. http://projectauriga.org/images/dropdown1.png shows a drop-down 
with more info pulled from a data store, in this case, an account, 
project, and task. For a line item, for example, we could populate a 
drop-down with product number and description.

Thoughts?

--
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com