Forum OpenACS Development: dumb acs object model questions
- Why are acs_object_types, acs_attributes, acs_datatypes and enum_values not acs objects?
- What do min_n_values and max_n_values in the acs_attributes table do? Are they min and max values for the attribute or the min and max numbers of attributes?
- Why not a required_p in acs_attributes?
- What is max_n_values in the acs_datatypes for?
- What is the real purpose for enum_value and enum_prettyname. It seems to just cause grief if you store the enum_value in the database since you have to convert to display and search.
- Why can't you put anything in acs_attributes.table_name
- It would be nice if acs_object.set_attribute/get_attribute worked like acs_object.name so you could deal with problem data.
- Why are acs_object_types not acs_datatypes so objects can contain other objects?
acs_attributes ... if they were objects one could use permissions to control who can read/modify object attributes on a per-type basis. The expense involved here would be relatively low. If each attribute value were an object (giving permissions control over attributes at the per-object level) the expense would be horrendous, so that won't happen.
min_n_values and max_n_values govern the min and max numbers of the attributes you can assign to an individual object. Obviously this doesn't work with attributes stored directly as columns in the object type's table, only for those stored using the (slower) generalized attributes table.
enum_value and enum_prettyname ... software engineers seem to believe that identifiers can't include spaces even if they're surrounded by quotes for some reason. :)
your last question is related to the first question and that has been discussed, too.
In general, I think you'll find that many would like us to move to a more lightweight object model rather than a more heavyweight object model, and some of your ideas might be viewed as moving towards the heavy end of the scale. In practice the more dynamic aspects of the object model are rarely used by package authors.
It seems the most used part of the data model is permissions. The meta data is rarely used. I just wonder if there would be more interest if there were more support. To me hooking the meta data to the form templating could be very usefull. The problem is I think they are some of the least used and least understood pieces of the toolkit.
There's a lot of duplicated functionality in the Content Repository (CMS/CR started as a standalone piece of software.) But the stuff there mostly/sorta works and is going to get better rapidly.
But, yes, using metadata to automagically generate forms and all that's has been/is being talked about and I think stuff will happen here in the next few months.
And, of course, if you're interested in helping out you are are more than welcome to do so.