Forum OpenACS Development: Response to Software Development (Bugs, QA, etc) and OACS

Collapse
Posted by Tom Jackson on

Talli,

I'm not trying to act too happy about my own software development, but you should take a look at two package I have which will greatly speed up the very boring parts of development. Togeather these two packages handle most all insert update and delete code for acs packages.

The first package is my package-bulider package. I have not converted this to pg yet, but it is available for use by all at: http://multi.zmbh.com:8300/ which allow you to enter your table definition and build both oracle packages and a set of pg functions for insert/update/delete, essentially this creates the pkg.new, pkg.set_attrs, pkg.delete, pkg.reset_attrs and pkg.pkg_p functions for oracle and the correspondingly named functions for pg. For pg, it also creates the package delete script.

The second package called query-writer. This package allows you to create objects which have attributes. For each object you can define function prototypes based on a subset of the attributes. Also, each attribute is protected with respect to the operations that can be performed on it. These protections are grouped (not necessarily an OACS group). Right now I use two groups: admin and default. It is relatively painless to add groups to an object. This is a relatively simplified system: a user is in only one group at a time, and right now only system wide admins are in the admin group, while everyone else is in the default group. However, what this all boils down to is that developers can direct all insert/update and delete operations to one page. This page also takes a return_url variable. During the processing of this page, any number of objects can be worked on. You can insert 2, update 3 and delete 1, of any object defined in the system.

I have been using this package with my merchant-system package, and I have got this thing to elegantly do everything I have needed it to do so far. Another big plus, due to the security groups is that the single query processing page can handle both admin and regular pages.

If the pre-built page is not able to handle a difficult set of requirements, you can use the tcl api which also has several levels of access. This also means that most of your .xql files will only be for regular sql select queries, which self port for the most part.

Please let me know if you want to see the query-writer package in action.