Forum OpenACS Development: Re: Idea: New Content Paradigm

Collapse
Posted by Tom Jackson on

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).

Collapse
Posted by Jeff Davis on
You pretty much have the view trick. Its a set of dynamically generated rules for views created to allow inserts into the view which do cascaded inserts into the parent tables. It's not an entirely general solution to invoking arbitrary plsql but on the other hand it makes building up content types from metadata quite easy. The end result is anyone creating a content revision only has to do a normal insert statement.

Its all in acs-content-repository/sql/{postgresql,oracle}/content-type.sql and in particular content_type__create_type, content_type__create_attribute, content_type__refresh_view.

In addition the cms system has code for building forms and performing the necessary dml for adding and editing content. It needs a little extension work since it does not support multiple forms per content type but it does work reasonably well already. So if you actually supply all the metadata thats needed you don't end up writing any dml let alone plsql.

Some of the work I am doing now will expose that API so that packages using the CR but not CMS will actually be able to use the cms automatic form generation/dml but not the full blown CMS api.

I looked at query-writer but I didn't really understand it completely. It would be useful if you had more sample code somewhere (although I guess since the metadata is all in the DB that's not so straightforward as it sounds right?)