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