Forum OpenACS Development: Response to Too lazy to code

Okay, so continuing with the query writer. Assuming all the attributes have been added for an object, visit the one object page and choose the second link, which allows you to build up a function using the attributes. (/qw/admin/objects/one?object_id=xy).

First note that if you don't want to use functions to insert, update or delete, you don't have to, 'IF' you use a single table to hold the object data (no acs_object) and that table has a single attribute as the primary key column. If you don't have functions defined, query-writer will use regular dml to do the work.

You add a new function by giving it a name a description and selecting the type: new, set or del.

Once you have added the function, you can click on the link in the table under 'Function Name'. A table listing all the attributes is divided into two sections. Initially all the attributes are in one section. To add an attribute to a function, you need to choose a default value and an order. Once you add an attribute you can update either the order or the default value, or you can remove it from the function definition. Attributes that are part of the definition show up in the top part of the table.

Default values can be different for the same attribute used in more than one function. An example of this is the primary key, or object_id attribute. The new function usually defaults to NULL, whereas there is no default value in the set function. If no default is provided, it means that a non null value is required. In the set function, the primary key attribute has not default value, all the other attributes have a null default. The set function only updates passed in attributes that are not null. Fortunately in postgresql, the empty string is not equal to null, so inputs that clear a form entry field are set to the empty string. This leaves the issue of how to set a field to null once it has contained something not null. A future version of query-writer will impliment the rst function which will reset the database value to some specific preset value. If that is not enough, I guess a nul function will have to be implimented.

Once all the functions are defined, you can print out the function bodies, and the drop script for the object.

On the /qw/admin/objects/ page, in the Current Objects table, the final column has a link to the pg-create script. The top part of the script will be appended to your object-create.sql file and the bottom part will become your object-drop.sql file. Sorry, right now you don't get a create table script.

Even though you now will have a working package, you still will not be able to use the qw.tcl file. You have to setup group permissions for the attributes and objects. Fortunately this is relatively easy.

The main admin page /qw/admin has a link to groups. One group comes built in to query writer: the admin group. If you want a special group for your package you can create a new group. There might be another special group called Default. These groups have nothing to do with acs permissions. A user can only be in one group for a given page request. The developer must write a script to define which group a user is in. As a guide, the admin group should be able to do anything, while the default group should be allowed to do only what the UI will allow, the expected use of the package. The main purpose of the groups is to allow developers to provide different features to different groups while having a single ui and backend. The idea is to provide a list of booleans for each group. The ui can use these booleans in the template if tags to 'white out' un supported values, or attributes. I still need to write the procedure to write these booleans, but they will be similar in form to the form variable names, so if you had a input variable named new.product.state.0, and the possible product states were 1-5, you would have booleans named product_state_1_p, product_state_2_p, etc. The backend already blocks hacking attempts using similar values. If you add a new group, choose some odd number that might be easy to substitute in the bootstrap file.

Assuming all your package tables begin with some nice distinguishing prefix like 'qw_', you can dump all this data into a bootstrap file so that you can package it up and give a copy to all your friends. Visit the /qw/admin/dump/ page and enter your prefix. You have to copy this to some convenient location so your startup script can easily find it. There is an example in the query-writer-init.tcl file.