Forum OpenACS Q&A: ERD for OpenACS/dotLRN
In contrast you have the data base itself (you can just use reverse engineering to get the ERD of the tables you are interested in)
and a pretty good documentation, both general and for every single package (some of them even with an ERD).
For the reverse engineering you have plenty of tools, I would recommend 'Case Studio' and 'Power Designer'.
I'm currently re-evaluating OpenACS. Without an ERD it would be hard to do. I can't believe things have change that much since the days of Arsdigita. Whether the schema has 200 or 500 tables it doesn't really matter. The value of a toolkit like OpenACS lies in its data model. There must be an ERD somewhere.
Don, are you around?
As for the changes, they are numerous, but the basics should still be fine. What is more important though for the evaluation as a Toolki is not the datamodell but the API that is provided to access the data modell (in my opinion).
I you want to create an ERD of the core functionality, install OpenACS in PostgreSQL and use http://www.rbt.ca/autodoc/ PostgreSQL autodoc to create a DIA script that you can use for the ERD. I have not tried this way, but I think Joel did it once.
Here is some of the core data model Data_Model_OpenACS.htm
And some probably too detailed documentation of every table
HTML descriptions https://openacs.org/storage/view/miscellaneous/oacs_5_kernel.html
Graphic of tables and relationships https://openacs.org/storage/view/miscellaneous/oacs_5_kernel.png
and the same graphic as a PDF https://openacs.org/storage/view/miscellaneous/oacs_5_kernel.pdf
Thank you so much for the links. I think this should do. Do you know if this data model and ERD apply to the latest version of OpenACS?
In your reply you said:
"As for the changes, they are numerous, but the basics should still be fine. What is more important though for the evaluation as a Toolki is not the datamodell but the API that is provided to access the data modell (in my opinion)."
The logic of the toolkit is hidden in its data model. The API is just an abstraction of that logic. However, there may be features and functionality not exposed via the API. The main way to determine that is to bypass the API and evaluate the data model.
The information that Deds provided should be included in the OpenACS' main information page or should be easily accessible.
In any case, thanks for the help in this manner and for the what you've done in the demo site.
On the other hand I have to agree though, that if you want to evaluate the *internals* of OpenACS the ERD should give you the best insights (I'm just thinking about the help this ERD will give us to better understand how to make Dynamic Types work ).
The OpenACS API seems to be well documented. What I didn't have access to was the ERD and all the other data model documentation. Now that I have both, I'll have everything I need to do a "full examination". At the same time, I may decide not to use certain aspects of the API and create my own implementation (different language, bypass the object model, etc.). In that case, I would want to "dissect" the data model a bit more.
In summary I would say that in order to do a thorough evaluation of any toolkit both the API and the data model should be examined.