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.
Example1: http://rmadilo.com/files/cams/www/one/
The index.vuh examines the url and chooses the template to use. The following urls are the same, the first goes through index.vuh:
http://whogeenie.com/cams/one/524/
http://whogeenie.com/cams/one/one?content_type_id=524
Example2: http://rmadilo.com/files/cams/www/archive/
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.
