Forum OpenACS Development: Re: How OpenACS coding could get its groove back

Collapse
Posted by Don Baccus on
We are much closer to being able to support rapid development than many believe. While Tom's query writer is one way to go, we can already generate content almost automatically from PROPERLY DECLARED content types (not general object types).

Here's a code snippet ...


        # Form creation hack!

        ad_form -name new-user -export {
            {parent_id $some_parent_id}
            {name $some_name}
            {other_stuff $some_other_stuff}
            {content_type phb_person}
            {content_method no_content}
        }

        # create the photobook user record.
        set id [content::new_item new-user]
        cr::item::set_latest_revision_live -item_id $id

Boom! A new content item with its latest revision set live ... now from this hack to an extension to ad_form that properly allows one to integrate properly defined CR types is not a large step IMO.

As far as xql files are concerned...I'm very, very loath to give them up. In fact I'd love to (in the far future) only pass SQL directly in the db_* API if one uses an explicit -sql switch - only for those rare cases where we need to generate dynamic SQL inline. Of course it's fine for one-off packages or packages that will only support a single RDBMS to avoid .xql packages - but this doesn't define packages in the toolkit itself other than some of the probe-the-db-schema type package work that by its nature is 100% db dependent.

But creating objects shouldn't require writing PL/[pg]SQL and already doesn't, actually - there's a primitive object creator for properly defined objects and as I mention above CR items have much more capability (if they're defined properly).

Now currently you have to "properly define" such things in PL/[pl]SQL, notably the tedious defining of attributes for CR items, but this is yet one more thing that can be done via a TCL API in a declarative way simplifying things ...

Collapse
Posted by Tom Jackson on

Just a note about query-writer: it applies to any database table. If the primary key refers to the acs_object table, you can use it to create new object types. Differences from the cr include the fact that you write down your data model: a real table with real constraints. A wizard is used to create the information necessary for query-writer to work. You just supply the table name and the primary key. You don't have to write any tcl or pl code in order to define your object type, that is one reason it is called query-writer! Once you have an object defined in query-writer you can use a tcl api to create new objects:


set object_array(title) $title
set object_array(content) $content

# create the object:

qw_new object_name object_array

Of course you wouldn't even need to do that if you use the supplied url api. This page, called qw.tcl takes form variables and processes them to create a series of qw_* statements. Processing includes running filters you specify on each attribute, and the newest version uploads files, runs multi-attribute filters and allows other callbacks to be executed. So for instance, the above title and content would probably come from a form. The form (this is all you would need to write) could be:


<form action=/qw/qw method=post>
<input type=hidden name=return_url value=@some_url@>

<input type=text name=new.object_name.title.1>
<br \>
<textarea name=new.object_name.content.1 ></textarea>

</form>

So once you have setup the object in query-writer, you can turn over the form entry design to someone else without worrying about them messing around with tcl and database stuff.

Granted, I still believe query-writer is difficult to get used to, and if you have a small data model, one or two tables, it probably isn't worth the hassle, this is the way with most tools.