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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
