First of all, thanks Matthew, this is great work. I've been looking through the datamodel and the ams package has some nice features. I'm in the process of developing a similar package and, to try to avoid duplication of effort,
I'd be interested in merging our work.
My aim with this package, as succinctly as possible, is to allow other packages to offer user definable object types using the AMS metadata and API to generate add / edit / etc forms and process the submitted data. Specifically I've developed a CRM package that will allow administrators to
define flexible user profile data that is entered at registration time.
I started from the form metadata code in the CMS package, ie:
- packages/cms/sql/postgresql/cms-forms.sql
- packages/cms/sql/postgresql/cms-widgets.sql
- packages/cms/tcl/form-procs.tcl
- packages/cms/tcl/widget-procs.tcl
and the attribute manipulation code in the acs-content-repository, ie:
- packages/acs-content-repository/sql/postgresql/content-type.sql
I won't go into details of functionality or specific requirements in this introductory post but I'm more than happy to discuss them. I'm aiming to have a working version in a couple of weeks but I can send you what I have so far.
I have a couple of detailed questions about your package (I got a good overview from ams/www/docs/index but still had some questions).
- How does ams_attribute_values work; is it for use when the acs_attributes storage type is set to 'generic'? is it an implementation of Lars' skinny table spec? (the acs-content-repository code above takes the dml approach and uses acs_attributes 'type_specific' storage type - that was the route I was following).
- Why did you choose to make ams_attributes subtypes of acs_object?
