I am NOT recommending that we redesign our system to be a laszlo backend :) I do find some of their concepts to be 'simplifying assumptions' that would make our lives easier. If we decide to generate XML output from our data with a specific tag, that should be easy.
One thing I really like, that laszlo touches on, but we can do as well, is the availability of front-end tags for displaying data results in a variety of ways.
They achieve this by always returning data in the same form they use XML and Xpath syntax, we can use TCL lists of lists or arrays of arrays or whatever we think works best in our environment.
A simple example of what I would like to see is a series of 'smart tags' that take a dataset and display it in the manner suitable to that tag.
Lets say an XQL query returns some rows with a variety of data, one field is the 'content-type' field. In our scenario now, we would say:
<multiple name="contents">
<h4>@contents.content_type@</h4>
<group column="content_type">
@contents.description@
</group>
</multiple>
To make that work, there are 3 different openacs roles involved.
First, there is a DBA who designs a dataspec, and writes out the queries associated with the tables.
Second, there is a programmer who writes a db_multirow to access that the queries. The db_multirow needs to be in the .tcl file associated with the .adp file.
Third, there is a graphic designer who wants to do a page layout, incorporating the data from the query.
I would like to eliminate step 2 (in most cases) by extending the tag syntax to include a pointer to the XQL query directly, with the assumption that we will always return data in a know format so the acs-templating library can handle arbitrary datasets.
So -
<fullquery name='myqueryname'>
<querytext>
select etc, etc
</querytext>
</fullquery>
<multiple name="contents" datasource='myqueryname>
<h4>@contents.content_type@</h4>
<group column="content_type">
@contents.description@
</group>
</multiple>
If I now decide I don't like the multiple/group display, I just change the widget. Let's say there is a date field in the results. I change my widget to say
<calendar name="contents" datasource='myqueryname defaultview="day">
<group column="posting_date">
<a href=@contents.description@>@contents.title</a>
</group>
</calendar>
Of course the exact syntax of each widget gets worked out, but that's the idea.
Add in pagination, grid, list etc... and spend some time on sites that you find by googling 'UI design patterns'
I'm intentionally ignoring forms at the moment. I think the ability to create less brittle displays of information is a key step forward.
The XQL should be like a file handle - it should be self describing, but not imply what context it gets used in.
The role of an XQL is to describe what in other contexts is called a datasource.
Like any idea, there are obvious branching points, I think the first and most obvious would be to extend the datasource attribute to include fetching xml-rpc,soap, etc data for local display. If we continue to use tcl lists of lists, then we would wrap that call with a conversion to our internal formatting. I think most of the work for this has been done, it's a matter of assembling the right pieces.
There are several additional things that would make our XQL files more useful. I'll stick to my top 2 for now:
Add a field for permissions required to access the query.
Add syntax to provide 'default/sample' data so a designer can work in an offline/not connected to the database local mode.
