A slightly related question if I mount two subsites they will both execute /SERVER/packages/acs-subsite/www/index.tcl which I think lists packages mounted on the subsite. How do people go about customizing the individual subsites?
In general you can customize individual packages, including subsites, to a limited degree by manipulating the "ad parameters" for the package instance. But I don't know of any simple way to have different Tcl code run for each subsite.
I've often thought that OpenACS would benefit from a package that maps a package instance to a physical directory. That would make it much easier to create the kind of one-off pages that often cause folks to fork their code.
Here's a sketch of a design. Borrowing some terminology from the java world, call the package acs-context-path. This package contains a file www/index.vuh that works as follows:
- Any request that maps to an instance of
acs-context-path is forwarded to index.vuh.
index.vuh uses the package_id to query for the instance's ContextPath parameter, which maps the package instance to a subdirectory of /SERVER/context-path-custom-contexts.index.vuh maps the package instance-specific part of the URL to physical files in the instance-specific subdirectory.
Note that the custom contexts directory is intentionally placed outside the packages/acs-context-path to allow for easy upgrading. Note also that this package functions sort of like a mini request-processor, and should re-use as much request processor code as possible.
I see this as a way to let programmers create highly-customized "gateway" pages to stuff that looks like standard OpenACS. In my experience, most customers have very specific ideas about how their homepage should look and work, but aren't as picky about the deeper module pages. acs-context-path, or whatever we decided to call it, would provide a relatively painless way to do this, giving the programmer complete and total control while supporting an upgrade path.
