Hi Richard,
thanks for the reply. Yes, I've seen that you have mentioned the OMS in "the specs".
So it looks as if we would then have to go ahead with our stuff, because we need a rasonable "extensible architecture" within the next few weeks for a new project: https://openacs.org/forums/message-view?message_id=239510
According to our current roadmap, we're probably just going to add some extra functionality to the existing acs_attributes mechanism:
- Extend the "acs_attributes mechanism" to objects different from subtypes of "group"
- Add some suitable maintenance screens
- Add the AMS widgets to acs_attributes, probably using the ams_attributes table
- Add some absolute/relative positioning to ad_form
- Maybe create a simple "form designer" to store ad_form fields plus absolute/relative positioning in the database
Our main focus will be to create a production-ready system ASAP. This means that we will not necessarily priorize "generality".
I understand that these extensions are more or less orthogonal to the AMS functionality, right? So by using
the AMS table structure we should be pretty much prepared to integrate these two development branches in the future, is that right?
One importante point though: We will need to remove any dependency on the "postal-address" and the "ref-*" modules from the AMS, so we are going to create a branch of the AMS, based on your current version.
Bests,
Frank
