Forum OpenACS Development: Re: OpenACS Attribute Management

Thanks Richard, Dave and folks for imposing some structure and starting to pin down the requirements for this stuff. Of the requirements discussed so far, here is the set, subject to agreement with Matt and the community, I would like to work towards, in the first release of the combined ams / dynamic-types package:

Attribute management as a service - Principally we are supporting developers who want to use dynamic types and metadata driven forms in their own packages. Specifically we are supporting:

Developers of 'empty vessel' applications - eg. a threaded discussion package which manages a hierarchy of messages but doesn't say whether each message should have a title, description, icon, attachment, etc or not. Instead these attributes of a message can be added dynamically after the application has been instantiated.
Developers of fixed datamodel applications who want to store data in the content repository without knowing the details of content_items and content_revisions or would like the system to take care of add / edit pages using metadata driven forms.

Extending (adding attributes to) existing types and creating new types - Whilst AMS doesn't support creating types from scratch right now, I got the impression from Matthew that he is keen to add it since all it really requires is to be able to store an object_id somewhere for each object instance. My dynamic-types package also supports creating new types. So, if I haven't mis-represented Matthew, we should aim for a combined package that supports both creation of new types and extensions of existing ones.
Support both acs_object and content_revision - Allow developers to create new subtypes of, or extend existing subtypes of, both acs_object and content_revision through the same api. However, I would specifically like to exclude the following, because of the impact I forsee on the simplicity of implementation (ie. so that we maintain the versioning relationship of content_item and content_revision as it stands currently):

Package developers may not version attributes independently of each other - when a new version of an attribute is created it must have a corresponding new version of the object.
Versioned attributes cannot be added to non-versioned object types.

I would interpret these requirements to imply the following functionality:

Provide a Tcl API to define object_types

create / delete object type
add / remove attribute from object type

Provide a Tcl API to define form metadata for an object type

create / delete form for object type
add / remove widget from a form for a given attribute of an object type

Provide a Tcl API to create and represent common combinations of form widget and datatype

create / delete a template to represent a datatype / widget combination (eg. boolean / radio button / options {{Yes y} {No n}})

Provide a Tcl API to add form elements to a form based on an object type definition
Provide a Tcl API to process form submissions to create or update dynamic object type instances
Provide a Tcl API to retreive attributes of an object or list of objects

Ideally I'd like to get those basic functions covered before looking at requirements like:

Permissions on object type metadata (ie. controlling whether someone can add / remove or edit the attribute metadata of a type)
Supporting composition relations (ie allowing an instance of a different object type (eg. address) to be an attribute of your new type)
Allowing modification of attribute metadata, along with deprecation (ie. moving and attribute from one type to another, or changing the datatype of an attribute)
Supporting object templates and list builder
Supporting multi-valued attributes

Forum OpenACS Development: Re: OpenACS Attribute Management - Requirements/Requests