Hi Andrew,
Pre-configured database content for demos and testing is
really, really cool
So you installed P/O using the Windows installer? It's one of the main features in our "sales process". And yes, every tester has the same base. And large pieces of TCL code are only activated once there are contents in the DB. However, putting the content together took us several weeks, and it requires special testing in conjunction with the installer.
I don't see why whether you save custom code in the
filesystem or in the RDBMS has any necessary relationship
with run-time extensibility
Please check for reference:
https://openacs.org/forums/message-view?message_id=239510 and
http://www.project-open.com/whitepapers/Project-Open-Architecture.pdf (the last slides)
The summary is: There are many types of customizations. The most critical type is probably the extension of "business objects" by additional fields and associated tables. Such an extions also implies (in a highly integrated GUI such as the one in P/O) that you show the extension information together with the original information on the object's "view page" and "list page". Extension modules need to modify these pages. So, how would you do this with listbuilder or portlets with the metadata under CVS control? What about two or more packages modifying a business object?
As an example: Please check the P/O Windows installer and install the "Project/Translation" preconfig (10 minutes on a WinXP box). On the "Projects" list page you can see in the last column a summary of number of "words" from a translation project. If you go to the "view page" of this project, you will see that there are translation information on the same page. However, you won't see these fields and "components" if you choose the "Project/ Consulting" option (please dont't use the preconfig, it's the same as P/T at the moment ...), .
This is a kind of issue that doesn't seem to get much attention in the OpenACS community because of the dominating "toolkit" approach. And that's ok, no problem. However, P/O (and a few other companies offering "products" and "solutions" around OpenACS) really struggle with this.
real and necessary technical design differences from other
OpenACS packages, but I don't think that's the reason
Loads of suspicion... Well, no surprise taking into account my previous posting. And yes, we moved away from the OpenACS core in some cases for licensing reasons (to be able to have "clean-room engineered" modules that don't fall under the GPL). However, the "P/O Architecture" slides were written long before we actually started the work, and "extensibility" was the main reason to discard listbuilder and portlets.
Bests,
Frank
