Hey Matthew!

this really sounds good, I'm looking forward to see contacts & ams in action ... thanks for the contribution.

This is one of the most significant developments in OpenACS this year. This package provides automatic form generation for attributes you add to any acs object. Very very cool!

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

1. 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).
2. Why did you choose to make ams_attributes subtypes of acs_object?

Lee,

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

This is my implementation of skinny storage - which is similar to any other ideas for skinny storage. It is a "generic" type of acs_attribute storage that isn't the same type of generic that is implemented in core, its more complex than that.

Why did you choose to make ams_attributes subtypes of acs_object?

Because all the acs_objects i know of used in openacs are subtypes of acs_objects. And they need to be objects because i need them to be able to have permissions.

Nima,

when do you expect release of Contacts 0.2a and when the final release of AMS?

Full AMS should probably happen within the next 2-4 weeks. It is partially dependent on contacts since contacts is being used to test ams functionality. Testing of AMS is needed and right now and if other people can test it and find bugs it might be sooner rather than later.

For contacts I could speculate, but the honest answer is I don't know. I am working on contacts with two other people and I don't have lots of time to work on it, and I don't know how much time the others have. So realisitically within the next 2 months for sure probably sooner than that, possibly significantly sooner than that.

If I understand you right. In future when creating a new package I define only the objects by myself and all it attributes by AMS?

That's right except AMS due to the nature of skinny storage isn't very efficient at sorting data. We are working on the best possible solution with contacts and the response to this issue we come up with will be in the docs. Right now i'm leaning towards ams managing attribute values and updating your acs_object table with sortable field data.

If yes, do you have a small working example I could take a look at (contacts maybe)?

A small working example of contacts is hidden in the ams/www/index.tcl file. Uncomment out the lines. In that example i associated ams_attributes to the ams_list object and then it generates a form and can return the values as a list or in an upvarred array.

One feature I think is important but not in AMS is the ability to extend an object types table. The code would be simplified and for extedning an object type in most cases would be sufficient. It also would make the queries much more efficient  for most applications.

I don't store attributes values as objects. I store attribute types as objects. This isn't nearly as heavy weight as attributes values being objects (which I agree would be prohibatively resource intensive if you ask me)... there certainly are significant performance issues involved in this and any skinny storage solution for that matter. I fully agree that we need to make sure this scales well. I really want this package to be heavily used and am willing to modify it to make this possible. Modifying object type tables might be the solution, but it also has drawbacks... we can talk about this on IRC... I agree that we should have a meeting. I'll be on IRC tomorrow (Monday) and set up and meeting time and agenda and then make an announcement.

Roc, Lee's package is the better one for creating pretty static dynamic attributes (meaning you set up the attributes at package instantiation time or for quicly creating custom packages), and AMS is better for attributes that can be added by any user at any time (this possibly createing a huge number of attributes). This thread should hopefully explain the differences between the two and give you an update on where they are headed:

http://openacs.org/forums/message-view?message_id=214574