Forum OpenACS Development: Improving (or replacing) acs_attributes for dynamic form generation

Collapse
1: Improving (or replacing) acs_attributes for dynamic form generation
Posted by Dave Bauer on 07/02/03 04:55 PM
Looking at dynamic form generation for CMS applications, we see that the existing CMS package stores it's own form specification data in it's own table including definitions of widgets, and the mapping of widgets to content type attributes. See http://cvs.openacs.org/cvs/openacs-4/packages/cms/sql/postgresql/cms-forms.sql?rev=1.7&content-type=text/x-cvsweb-markup

Most of this, I think, can be generalized to work with acs_objects.

If we want to pull this out, should it be a seperate package, or part of acs-templating, or acs-kernel, or something else?

I want to get this started in some direction. This is one of the useful parts that is landlocked in CMS currently.

Ideas?

Collapse
4: Re: Improving (or replacing) acs_attributes for dynamic form generation (response to 1)
Posted by Robert Locke on 07/02/03 06:02 PM
Hi Dave,

You may want to look at this thread for some ideas as well:

https://openacs.org/forums/message-view?message_id=28086

Collapse
3: Re: Improving (or replacing) acs_attributes for dynamic form generation (response to 1)
Posted by Tom Jackson on 07/02/03 06:06 PM

It would be great if this information was available for all acs_objects. Acs_attributes sound like a good place. It could possibly still be an add on package, but if it worked it would probably move into core pretty quick.

One problem with automatic form generation is that usually there are attributes which should only be accessible by certain users, some not at all, and some, only certain values should be available. Unfortunately the database doesn't know about any of this, so these details are handled in the tcl layer.

For efficiency, the data in this system should probably be cached in nsv_ arrays.

It is a tough problem.

Collapse
5: Re: Improving (or replacing) acs_attributes for dynamic form generation (response to 1)
Posted by Dave Bauer on 07/02/03 06:34 PM
Tom,

Off the top of my head, adding a "context" to each attribute might solve your problem. This would work if each application used it's own tcl procedures to generate the form. Context would be an application specific definition of when to show an attribute. So an application would determine the context based on permissions, or any other data, then pass this into the code that generates the form, which would compare that to the context set for each attribute.

We could default to NULL which would mean always show, and if context is not specified when geneating a form, show all attributes.

Anyway, something like this would probably work.

Collapse
6: Re: Improving (or replacing) acs_attributes for dynamic form generation (response to 1)
Posted by tammy m on 07/02/03 11:01 PM
Hi Dave,

I have been using a package I created mostly from classified-ads code to generate forms from an extension table to acs_attributes. It works for me thus far. If you would like to take a look at the ideas I got from Deds Castillo's classified-ads code, I can send you a tarball of the package as it is now -- which is usable but not completely setup; like dependencies are not filled in, it obviously needs Templating, CR and CMS;)
It also uses it's own widgets table which is very close to the CMS widgets and I do think this widget table should be shared by CR, CMS, Templating + the FORMs generation code if at all possible. It's way too confusing having duplicates.

Some of this code I think should be in the CR or the CMS, I think I commented it where I thought it was applicable.

Anyway, if you are interested, send me your email and I will send it to ya for kicks.