I am responding in a different thread to start the actual discussion on this item: https://openacs.org/forums/message-view?message_id=178384
Dave: The underlying idea is that if OpenACS is going to be both in the
eLearning space, in KM, and in
whatever-website-you-happen-to-build-for-your-grand-mom business, then it will
have to allow for customizing the user interface. For example, if you have a
site that only needs one forum, it should be trivial to get rid of the page
listing all forums in a package instance.
Currently that requires manually changing files in the packages/forums/www/
directory, which means you're now going to have trouble upgrading.
Second, the ability of users or superusers to tweak and make changes to the
user interface is a major differentiator in the .LRN market. None of the big
players support this (for obvious reasons), and everybody is doing it -
Heidelberg, Mannheim, Bergen, Vienna, Sloan.
Now, my thinking is that browsing objects in the CR is different from browsing
pages in the system. In a traditional CMS system, in the back-end, you'd have
one page per news item, for example. In OpenACS, we have one news-item page,
and it takes a parameter of which news-item to display. I want to keep things
the OpenACS way, because that's what a dynamic web application platform should
look like, but I'd like to (a) make it easy for people to customize UI to suit
their users, and (b) do so without forking code, and (c) have a back-end UI to
help them.
Now, we talked about where to store such a thing, noting that there would be
advantages to being able to use version control for this (it's essentially UI
development), and Jeff suggested just storing it in a /local directory.
I think there are two issues here. First customizing package code for local needs. This is easy to do. Using a subdirectory called local is a good idea. I wrote a two line procedure that can check in another directory before going to packages in the request processor. I even was able to let it find an ADP page in the /local directory, but still use the tcl scripts under the pakcage directory if you just wanted to change the adps.
Now. One reason I looked into storing these items in the content repository was to offer a web interface for designers. At this point I think a WebDAV interface would be better, but you still can use OpenACS access control to the files, so designers don't need a login to the server itself. This does not mean the ulimate files served to the user are taken from the database, the CR already supports publishing templates to the filesystem. It would be possible to then integrate those published files with CVS.
The other issue is that there is no reason NOT to use the content repostiory features to serve a tempalted news item instead of having the new display be only in the filesystem. Using a template definied by the content repository template assignment features does not in any way change how OpenACS works. If you put all the news items in a foler and named them with the news item_id, the url would like this this: /news/12345 and would work just like it does now. There is also no reason the template code couldn't extract the news item_id from a query variable in the same way it does now.
Right now the trick is coordinating the tcl code to generate a datasource for a content repository item. Currectly the code that pbulishes a template looks for a correspsponding tcl file parallel to where the adp will be published, and if one does not exist it generates a tcl file that can create a datasource from the content type definition.
When we have a tcl procedure to generate this datasource per object type it would be easy to generate this automatically. To add additional "things" to a page besides just the one item, the current system of include and master templates would work just as it does now.
Comments?
