Re: Proposal/Question: Object broker/dispatcher for alternative templates

["Chris Travers" <..hidden..>]

On Mon, May 19, 2008 at 9:44 AM, John Locke <..hidden..> wrote:
> 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.

This is already part of the 1.3 framework.  Basically, you have
controller scripts (in scripts/) and a template engine with multiple
backends (LedgerSMB/Template.pm).  Adding JSON support (or any other
format) should be reasonably easy.  We already support:

LaTeX
HTML
Text and CSV

>
> 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.

Pretty similar to the new architecture in 1.3, actually.
>
> 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.

This is pretty much exactly how the Template.pm and its backends
handle things now.  A controller script passes things off to a view
which includes information about the format and template being
processed.  This is not quite divided along standard MVC lines but it
is very close (most changes are due to database-centric models and the
necessity of handling views in a way condusive to a stateless web).

>
>
> 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.

That is generally our plan.

>
>
>
> 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.

It should be possible to either:
1)  Edit the LedgerSMB/Template.pm to recognize a flag to allow MIME
types to be declared in-document.
or
2)  Create a new backend (LedgerSMB/Template/JSON.pm) based on the TXT
and CSV backends.
>
> 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?

This should be reasonably easy for new-framework code.  Code which has
not been refactored into the new framework will need to be moved
first.

Otherwise, this should be pretty doable.

One other add-on element I would suggest is a new key to defaults
which specifies the initial path for templates for a given company.
This way new templates could be installed somewhere for a UI and then
used from there company-wide.

Best Wishes,
Chris Travers