Extend datamodel to support forms
Below is a table with the arguments for form elements and possible data to populate them.
Element            Current Data            Proposed Data
widget                                     datatypes.widget       
datatype           acs_attributes.datatype
html                                       attributes.html     
options                                    ???
value              acs_attribute.default_value
values                                     acs_attribute.default_values (multi value)
validate                                   datatypes.validate (multi value)
optional           acs_attributes.min_n_values/max_n_values 
Should validate/widget be part of the datatype or attribute?
I'm for making datatypes acs_objects.
This does a couple of things.
First it allows access control which might be needed for some kinds of RAD tools.
It also adds a parent/child relation to the datatypes.
This is usefull in a number of ways.
Create a few types such as number, string and long_string.
If I want to collect animals I can create a datatype called animals with a parent of string.
I don't really need a new widget or validate routines.
If I like dogs I create a new type dogs and make its parent animals.
I still don't need new validate routines.
Now if I only want pure breed dogs I can create datatype called purebreed with a parent of dogs.
 Next I create a table of valid types and validate against that.
The widget can also change to a select list.
If the user has write access to the datatype they could add a new breed.
Finally this allows finding all the animals or dogs in the system.
Multiple values per attributes
       
The current datamodel is incomplete when it comes to multi value storage for one attribute, but
html forms allow this.
The min_n_values/max_n_values imply you can store more than one value per attribute but the data
model but it's not clear what happens if you set max greater than 1.
I think the way to do this is add a new storage type called generic_multi and create a table like:
key
field_id
object_id
v_object_id
v_number
v_varchar
v_clob
key is a primary key
field_id/object_id are unique
v_object_id must be an object_id
This would require a new set of acs_object apis like get_multiattribute, set_multiattribute and
delete_multiattribute.
This allows some kind of typed storage as well as objects to be stored inside objects.