Forum OpenACS Development: Re: Proposal for hooking forms to metadata

I think Tom's work also includes code to generate package/proc stuff (new?) and that's also duplication of effort of code that already exists in acs-subsite.

Don, please. This writing of the 'new' function for a package is a tiny tiny part of what query-writer does. This code isn't 'duplication', because the functions are generated from data that is necessary to write the queries for insert/update/delete. Query-writer already can write regular dml for these operations, if you don't supply functions (in case it isn't an acs object).

If you use the url based api, you can easily put any combination of attributes on a form for insert/update/delete and have all submitted attributes checked for whatever filters you specify. In addition to the regular filters available, you get automatic checks that the length of each attribute will fit (for varchar). Permissions are checked for any number of attributes on an insert/update (for delete there is usually only one).

For instance you could have an invoice which is generated from data from a number of tables, say invoices and invoice_details. In one form you could update attributes from the both tables, including all the rows of the details. You could delete rows, or add completely new rows all with one click. None of this requires anything more than writing the form and directing the form to the qw processing page.

However, since it is a url based api, you don't even need a form. A program could issue a GET or POST of the proper form to do the insert/update/delete.

Although the examples available in acs-subsite, group types and cr/cms do a few things that resemble this, these efforts are narrowly focused and incomplete.

Also, my code has actually been used to create a useable package of many many pages.

I would not recommend using my package for acs-core, or for specialized cr/cms applications. It wasn't designed for that. I wound not recommend using it for a one or two table datamodel either. I would recommend using it if you are writing an application with a lot of object tables.

This is just what the current query-writer does. The new and improved version will be easier to use and more general in application. As it stands the current query-writer is annoying to setup.

Anyway as far as I can tell most apps work by sticking their data into tables (or updating and deleting it), data gleened from forms submitted by users. This is what query-writer handles. It doesn't write forms, it doesn't select data from the database. It also controls access to attribute values, not just attributes. And it caches all the info needed to work, without hitting the database.

Writing the pl code is really a side effect. Someone or some thing has to do it. My tack was to generate a first stab at some pl and allow the developer to copy/paste it to the sql directory and edit, if necessary. The new version will be a little more developer friendly in this respect. So neither version is dynamic like what you find in other code examples. On the other hand, query-writer can be more general and handles overloaded functions. None of this could have been achieved by starting from the other code.

I believe that your intent, which I agree with, is to get everyone to join forces and come up with a general solution that would satisfy everyone. I would of course not mind doing that, but query-writer is necessary for my own development work. I doubt that anyone else is even using it.