Forum OpenACS Development: Re: Customizations

23: Re: Customizations (response to 22)
Posted by Don Baccus on
"One of the ways that I have done this in the past is to create a "shell" package. i.e. lets say project manager is heavily customized for the client. Then you create the package client-project-manager with www/index.vuh that defaults to converting the url reference to all files in project manager. Then for those files you need customized you can tell that custom packages index.vuh to reference the custom version instead. "
This is a stripped-down variant of the notion I have of (eventually) being able to declare packages subtyped from parent packages, using an index.vuh file to serve either the custom or generic package files manually.

This gives you a way to do the customization that doesn't require hacking core with a kludge, or waiting until perhaps (someday??? never? :) something more generalized is implemented.

This shouldn't require mounting of the parent package (as I imagine implementing derived packages this wouldn't either), but rather your custom package. As dave says, the RP will find your custom templates in the mounted custom package. Your index.vuh file can then manually return the /packages/parent-package/www/* template file. If the parent package is installed but not mounted the tcl libraries will be loaded, so you'll be set, no?

If you try this out and it works well for you, tell us all about it :)

24: Re: Customizations (response to 23)
Posted by Gustaf Neumann on
the s5 package is an example of an implementation of a derived (subclassed) package. The package s5 ( ) is derived from xowiki. See for the original posting. i have not done any work to subclass package parameters.
25: Re: Customizations (response to 23)
Posted by Tom Jackson on
The CAMS package demonstrates this very well.

The idea could be easily applied to any OACS package with a few small edits to existing scripts and an index.vuh file to handle the details. This is different than what I have discussed before.


The index.vuh examines the url and chooses the template to use. The following urls are the same, the first goes through index.vuh:


The index.vuh file does a little more here. The url is again examined, but the url parts are turned into a date and put into the form with rp_form_put. Then rp_internal_redirect is used to go to the real page, which could be accessed directly.

So the point here is that the passed in urls don't match any files, so they get caught by index.vuh. So in an OACS package, you could put a url part that indicated which instance or subclass was being accessed. This could be used to rp_internal_redirect to the correct tcl file...or with a few more changes to the tcl file, you could just specify the template.

What would be needed is the index.vuh file to use rp_form_put to insert a template path/name. Then the tcl page would need to end with ad_return_template $template. This editing could be done by the lone developer, or become part of the package at some point. Another possibility is a simple unix trick. Instead of editing the tcl file, just add the index.vuh file which redirects to a special name:

rp_internal_redirect customerA-one

Since the Tcl file doesn't need changing (in this example), just make a symlink from one.tcl to customerA-one.tcl and add a new template file customerA-one.adp.

This means that the template file must be stored in the same directory, which might not be okay, or maybe not. Maybe the index.vuh file could redirect to the templates directory and the symlink could go to there. Worth a try.

I think a fully supported method would be a little more tidy, but would probably require a few core changes. These ideas can be tested and integrated with current packages as needed by end users or package maintainers.