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

Collapse
Posted by Don Baccus on
Have you looked at add_form_elements in acs-subsite/tcl/attribute-procs.tcl?

There's a bunch of other attribute metadata Tcl wrappers in there, too.  Not all of it works.

Anyway ... as I mentioned earlier there's duplicated (but more sophisticated) code in the content repository that does similar stuff.

What we really need to do is to plan out our strategy to do the automagical form generation, data insertion, data editing stuff so that we can look forward to the day when we have one API to do so that's comprehensive and works.

Then we'll be able to lash together packages with a lot less effort and if they can be done through a decent API of this sort, can have them support both RDBMSs out of the box, to a large extent.

Your demo's slick but it represents a third code branch which works towards using metadata in this way.

We may be stuck with two due to there being so much redundancy in the CR of features found in the object model and these features in somecases are grafted onto rather than organically part of the rest of the toolkit.  Merging is probably more a medium-term than short-term proposition.

But ... let's work towards having one fully-functional API for standard objects rather than work in parallel!

There are several of us currently interested in, and to a varying extent looking into, solutions.  You, Lars Pind, me, Jeff Davis, Dan Wickstrom at the moment (there are others, I'm sure)

How can we best coordinate our efforts so we don't double up?

Collapse
Posted by Jeff Davis on
Tom Jackson's query writer also covers some of the same ground. It's worth having a look at it as well.

The problem with the stuff driven from the acs_attributes alone is that the attributes don't really tell you enough about what widget should be used or populate select widgets etc. cms has that additional data for driving widgets (cm_attribute_widgets, cm_attribute_widget_params are the two tables, content::new_item_form is the form creation code) and it lets you do quite fancy things but the datamodel presumes that there will only ever be one form for editing a given content item and also the code forces you to edit one object at a time. For real world problems you end up with several interrelated objects you want to be able to edit simlulaneously (for example, an article you might want to be able to edit the list of associated photos, the author data, title, blurb etc. and it's probably the case that that is at least 3 content_items (probably even more than that).

Anyway, I think driving the UI from metadata is a great idea and am a big fan of doing it that way but I also think we need a better datamodel and better supporting code so that our saving programmer time won't come at the expense of creating horrifyingly bad UI experiences.

I think one place where we fall down now is in not having nicer higher order input widgets (like a standard address widget or phone entry widgets) and doing multifield validation (oh and not signing enough variables but thats not a UI thing).