I wish someone would outline the 'view trick', because reading the source is giving me a headache. It looks like some pl code creates a view which is a bunch of joins going going back to acs_objects. What I saw is very specific to the cr/cms system. Then a rule is created which runs when someone tries to insert on the view. The rule consists of running one of the cr_*__new functions and then inserting stuff into another fixed table.
What you end up with is a bunch of pl code that is auto-generated from a set of acs_attributes.
That is all nice and good, but it is only a small part of what query-writer does right now, and is very specific. The new version of query-writer will be more generic, will produce very little pl and it will write the pl to a file mixed with custom, hand-written code, if necessary. Query-writer also caches all the variables it needs, so no additional db overhead is created when insert/update/delete are performed.
One reason I wrote query-writer to begin with was to help manage the form generation process and help multiple classes of users use a single form. Query-writer does this by allowing the developer control access to attribute values, and to the operations (new, set, del) on every attribute, or attribute value.
So far, the examples I have seen in OpenACS are limited in what they do to a set of hard coded methods. They all use pl to generate more pl. This doesn't mean the ideas are not good, but they are far away from being generally useful.
Query-writer doesn't solve all ills either. The main thrust of the package is to make new development follow a consistent set of methods for insert/update/delete on objects, and control who can do what with an object/attribute/value.
The merchant-system package I wrote has 19 object tables. If you have an app with one or two table it doesn't really matter if you custom write everything, but with 19, it is a problem. The unicycling website I am working on will likely have at least that many object tables. The current version of qw could work for this already, but I am so lazy that I want it to do a better job. Simple development of the sql code should be a little slower than writing the datamodel (create table), but it should also bring quite a lot of extra benefits as well.
I know there is some concern about the limit of 16 attributes per function in pg. I think this is compile time configureable, so in the unlikely chance that an object requires more than 16 attributes with no defaults, maybe a recompile of pg would be easier than forcing the creation of views and rules for every case and every one who uses OpenACS.
The current limit for query-writer is 32 attributes. Unless the size of an integer value can be bigger than 32 bits, this would be the upper limit. (Query-writer uses bit-wise operators to choose a matching function).
