Forum OpenACS Development: please explain the decentralization of reuseable info in openacs (such as home address, business address, etc.)

Request notifications

Hello, I have been looking through the code for various packages
built on top of the openacs core as well as the core itself, and have
come up wondering… why is there no consistent way to store detailed
user info? This is not so much of a critique, but more of an
inquisition as to why a certain data model was chosen.

For example, the ecommerce package has its own tables for shipping
address (which most of the time would either be a home or business
address). Likewise, a package from ybos for event registrations
stores this info in its own tables, and dotlrn stores user info in
separate table. Why wouldn’t this information be stored in the
acs_attributes table, much like the personal bio is?... where the
acs_attribute bio references the acs_attribute_values table… and then
the packages that need this commonly used information would reference
it, and if those attributes didn’t exist it would create them…

I realize the reason to separate out custom info that only pertains
to a certain package, for example, the cost of an item in the
ecommerce package is something that only pertains to the ecommerce
package… but home address, city, phone number, business address,
city, fax, etc… to me seem like things that should be centralized.
Could somebody please explain to me the thinking behind the de-
centralization for these things?

Explaining the thinking would be difficult since the there was none (or not a lot). The ecommerce system was written in the early days of the acs and was ported to work with openacs4.x so there are a lot of either duplicated or poorly related data. I am not sure but I think the ybos events module was a 3.x port as well. Certain parts of the of the data model are quite well thought (kernel, content repository, etc) out but you need to recognize that a lot of parts were written at different times and hence don't quite gel they way they should.

Ideally we would rationalize a lot of these and remove the crufty bits but to date no one has stepped forward to do it.

I have a small data model as a subpart of the merchant-system package that allows you to attach addresses to any object_id. Not sure if this is useful or not, but it isn't necessarily part of any other package. Anyone want a copy?

Once acs-person is done, I will work on the generic acs-address (also using HR-XML standards).

This has been planned for, just search the boards. Also, the locales project knows about this so it will be completely international.

Forgot to mention, acs-person will be in 4.6. acs-address will be a little after that.
Thank you everybody for your responses.

Jeff, your explainations certainly make sense

Tom, i would be interested in taking a look at the subpart of your merchant package... it sounds interesting and may be something i could model my events/registration package after (I want ot make it customizeable enough that you could easily accept job postings through it as well as signing up for events like a conference - by using dynamically generated information-collection pages - that can be templated)...

Jon, acs-person and acs-address sound like what i am looking for. i went into cvs (anonymously) and tried to download acs-person, but it said the package wasn't available. is there some place i can go to look at it before the release of 4.6? am i just using the wrong command?

#  cvs -z3 -d co acs-person
Should i be checking it out of some other server? How about acs-address?