Forum OpenACS Development: Extending acs-subsite

It seems to be pretty common practice for a site to customise acs-subsite to do stuff like add extended user information, modify the user registration pages, partition the users and create a users home page.

This got me to thinking that it would be great if any package, eg. a project manager, which glued other packages together was able to act as a subsite.  So I started wondering whether it would be possible to 'extend' acs-subsite (ie. inherit and override its behaviour)...  or in some other way create an independent package that would customise the behaviour of acs-subsite.

Much of the acs-subsite ui has been made available as re-usable components in the lib directory...  so creating a package which extends its pages should be straight forward... are there other parts of acs-subsite which would be hard to extend and override?

One idea I had was to create a parameter to specify a file to internally redirect to for requests under acs-subsite.

Using this the requests would be redirected to an index.vuh page. This way edit-this-page or a CMS could handle requests under acs-subsite without moving files around.

Randy,

That is not quite it. That does an ad_returnredirect and causes the vistior's browser to request a different URL.

The idea I have is to internally redirect requests. This way, a package can appear to be mounted at the same place as an instance of acs-subsite.

Effectively it is the same as symlinking in the index.vuh from edit-this-page in the pageroot.

The problem with using an internal redirect to some page instead of a browser redirect is that relative URLs will be interpreted wrongly - the browser is unaware of the real location of the page. So if you do an internal redirect to some-package/index from the acs-subsite index, and some-package/index contains a link to some-package/one?id=111, following that link will cause the browser to request the page 'one?id=111' from the acs-subsite package. Which doesn't exist.

I think the result of this is that a simple internal redirect (to a page) won't do the trick, and some clever use of a VUH is required. I guess you _could_ have an index.vuh in acs-subsite to handle the internal redirects to some other package, but as VUH's are last in the request processor pecking order, any pages still in acs-subsite's www directory would take precedence.

Lee,

Very interesting.

I also had the idea to have another package pretend to be acs-subsite in the context of dotLRN, so that packages under a class would be able to calculate the class home by using the same procedures as if they were mounted under a subsite.

Your experiments seems to support this idea.

What do you do about the user pages under acs-subsite?

Redirecting back to acs-subsite would be useful for stuff like the sitemap and 'shared' pages definately.  The user pages in particular are often very light wrappers around reusable includes in acs-subsite/lib so for most of those I'll probably copy and modify the wrappers.

Lee,

Really some of the "glue" in dotLRN should make it back into acs-subsite. I definitely want to be able to serve pages from a CMS but use the community features of acs-subsite.

Don,

Those would be good extensions to cover of a few of the most common customisations which would only require configuration through the ui.  But having the subsite api explicitly support developers who want their own package to act as a subsite would be a great way to allow more complete customisation right?