Forum OpenACS Q&A: mounting a package on /

ad_page_contract {
  packages/editthispage/www/index.vuh

  @author Luke Pond (dlpond@pobox.com)
  @creation-date 2001-06-01

  Virtual URL Handler to serve files from an
  instance of the Edit This Page package.

  Helpful .vuh example at
  http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg_id=000JTn
} {
        {revision_id ""}
}

ad_conn -set revision_id $revision_id

# get the portion of the url following the package directory
set name [ad_conn path_info]

#ns_log Notice "index.vuh: request for $name"

if { [string index $name end] == "/" } {
    # it's in a subdirectory, and we know there's no
    # other package mounted on that subdirectory.
    ns_returnnotfound
}

set server_root [file dirname [ns_info pageroot]]

if {[empty_string_p $name] || $name == "index"} {
    set path "$server_root/[etp::get_application_param index_template]"
} elseif {[string match "etp*" $name]} {
    # this trickery is for serving pages from the top level,
    # where the acs-subsite package is mounted rather than
    # the editthispage package.  normally the request processor
    # finds these before invoking this file.
    set path "$server_root/packages/edit-this-page/www/$name"
} else {

    set path "$server_root/[etp::get_application_param content_template]"

    # set up form variables so we can pass the "name"
    # variable to the content page.
    global _ns_form
    set _ns_form [ns_set create]
    ns_set put [ns_getform] "name" $name
}

ns_log Notice "Edit This Page index.vuh: serving $path"

rp_serve_abstract_file $path

We recently got this question on the #openacs irc channel also. We suggested redirecting to the proper place so the user will end up at /ecommerce/ or whatever you call it.

A nice generalized solution to serve content from the site root would be great.

We talked in Copenhagen about a more general facility for subsites to do something different, for instance to return a portal page rather than a template page, but that lies in the future.

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:

1. Any request that maps to an instance of acs-context-path is forwarded to index.vuh.
2. 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.
3. 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.

Yeah, good point. Everything I described above can be achieved by simply overriding URLs in www. One thing to note in this approach is that non-overridden URLs will still be accessible (e.g. http://mydomain/students/register/permissions/one.tcl?object_id=0), which may or may not be what you want.