Forum OpenACS Development: Response to Too lazy to code

Collapse
Posted by Tom Jackson on

Although the url method is useful, there will arise situations where more custom code is required. The internal api for the query-writer is very simple. To use the api, you have to construct an array holding the attributes:

set myarray(name) "Product1" set myarray(description) "One great product!"

Then you can call the qw_new proc:

qw_new product myarray

This api does not perform filtering or permission checking, but it still performs any extra eval's specified for the object. Updates and deletes are just as easy:

qw_set $obj_id product myarray qw_del $obj_id product

The query-writer package has a complete admin ui for adding objects, attributes, groups, functions, assigning attribute access permissions and dumping data for a particular package of objects. It also has numerous examples of use: some of the query-writer object tables use the qw.tcl ui. All database values used in the query-writer are loaded into nsv arrays. The operation of the query-writer does not require any additional database activity above the inserts, updates or deletes being performed.

Currently lacking is a helpful form variable holding the current value of the attribute. These will start with 'cur'. This will help weed out unchanged values in a form for updates. Also missing is after a delete, any corresponding set array should be deleted as well: you cannot update what doesn't exist. I stubbed into the data model additional permission checking, but it is not supported yet.

The current setup only works for PostgreSQL. However, there are six procs which handle the formatting, dml and pl for new,set,del. These are carefully separated. The names are specified by the developer, so to port the query-writer to oracle, you need to write these six small procs and then specify the names you use in the datamodel that holds these names. You do not have to edit any of the query-writer code. I estimate this will take no more than six hours.