Forum OpenACS Development: Re: Rich internet apps on OpenACS

Collapse
Posted by Don Baccus on
Rather than bury presentation information in .XQL files, which means it might need to be replicated in both PG and Oracle files, which means in time the two version will drift and/or one will break, our maintenance resources being what they are ... and seeing as duplication is something to avoid anyway ... And seeing as having some HTML buried in .xql, some (gasp, still, though we work to get rid of it) in .tcl, and much in .adp files ... Why not investigate modifying some of the more useful tags to take an optional datasource? For instance, your "multiple" tag would fit wonderfully into an .adp file ... When we eventually finish automatic generation of forms and perhaps output lists by making the maintenance of datamodel metadata much easier than it is today and move some of the CR ideas over to mainstream ACS objects ... one can envision that perhaps "formtemplate" and "listtemplate" template tags could just take a datasource directly with some parameters if one wants to autogenerate simple forms/display pages. Still, when all is said and done, at the moment I don't think our generation of tcl/xql/adp is the main issue in regard to rapid development. It is the tedious building of the datamodel and supporting procs that slows me down the most. We're working on fixing that (ever so slowly). Even today, proper providing of metadata allows one to automatically generate new objects with a simple tcl proc call that supplies the datatype and form name ...
Collapse
Posted by Alfred Werner on
Don - the original proposal /discussion <b>EXACTLY</b> what you are saying. The only thing discussed in adding to the xql files were two things - a permissions attribute (so the coder knows what the intentions are - ultimately that would be enforced by the page) and 'demo data' - sort of the lorem ipsum of database queries, so a UI person could work on pages in 'artist mode' which would not execute actual queries, but only return sample data. The original suggestion was to add a datasrc flag to the adp tag libarary (and to extend the tag library) and go DIRECTLY to the query without intermediate tcl code, since the tags are really tcl code anyway. example (without looking at real xql syntax or permssions naming): <xql><query name="onethread">select topic, poster, posting_date from forum</query> <permissions>public</permissions> <data><topic>Re: Re: Rich internet apps on OpenACS</topic><poster>Alfred Werner</poster><posting_date>12/10/04 12:16 AM</posting_date> </xql> You can then use a tag in your adp page : <multiple datasrc="onethread" paginate=yes perpage=25> @stuff@ </multiple> Since there is a date field, you might decide to use a calendar widget instead: <calendar datasrc="onethread" defaultview="month"> @stuff@ </calendar> That's the general idea ... Main focus will be to identify a core set of tags and their semantics, and to eliminate the middle tcl layer unless necesary for customizations.
Collapse
Posted by Alfred Werner on
doh - bad formatting choice!

I'll post a cleaner example at some point.

Main idea -

xql has the query and a name.

in the pages:

<mutltiple datasrc="forums" paginate="yes" perpage=25>
@stuff@
</multiple>

you switch to a calendar view:
<calendar datasrc="forums" datefield="posting_date" label="topic">
@stuff@
</calendar>

In most cases, you shouldn't have to put a tcl layer between the adp and xql to use this ...

Collapse
Posted by Mark Aufflick on
As one who now spends the vast majority of time on programming tasks not including OpenACS (and therefore someone who's views may be out of step with the current OACS community) I agree with Don that the worst time waster in an OpenACS project (especially starting a new one) is the datamodel + procs creation process. You *could* automate some of that, but if you have to rely on code generation I think that reflects an underlying issue (as in the bloated Java web frameworks).

That's really what people love about Rails. Sure Ruby is much nicer to write than TCL, but when you start an OpenACS package you are writing sql, pl/pgsql and then tcl.

If you could define a subclass of a content repositary object and that did all the work for you, then you'd be cooking.

Working at the code level for subclassing (rather than the rdbms level) also makes it easier to upgrade to things like lazlo later since added functionality in the base class will bubble up.

Collapse
Posted by Malte Sussdorff on
This tedious work (of the helper procs and datamodel generation code) was the reason why we created the package-builder at one time. It is far from perfect and probably the other approach taken with UML is considerably better, but maybe someone is willing to invest some time into improving either one to make code generation considerably simpler. If you have all the code for your add/edit/display/list of "objects" ready at hand, then you could (quickly) modify it to suit your needs.