Forum OpenACS Development: Customizations

Nima brought to my attention a different way of doing this and I wondered if this would be useful for OpenACS. He can explain this probably much better than me, but the general idea would be the following.

In addition to *.tcl or *.adp allow a *-custom.tcl and *-custom.adp. The request processor would then be smart enough to serve the "-custom" file if the "-custom" file exists instead of the normal one. So if we have index.tcl and index.adp we could make our customization by copying index.tcl to index-custom.tcl (same for .adp) and prevent the fork. An update from OpenACS would then update the original file, but we could retain our version and do a manual diff to decide if we want the latest features or not.

What do you think about this method?

Two additional thoughts:

1. the naming should be a parameter
2. the customization should be configurable on subsite level. Maybe we provide a default word like 'custom'.

This would allow a single installation of OpenACS to serve different customized versions. The request processor can check for each subsite whether customized pages exist and serve them.

Another extension to 2. would be to lookup customized files automatically. Thus if I have a subsite foo and a subsite bar then the request processor checks for *-foo.tcl and *-bar.tcl file to serve.

I agree to Dave that we need to have customization on instance level. Thou I believe that on subsite instance level is enough.

Having an "off" switch will most certainly help. Caching does not make any sense in my opinion. But to speed things up I would use a delimiter not commonly used in URLs, like "index+custom.tcl", so the RP can very quickly check if there is a file that matches this pattern in the file system (if we were to use "-" this will bring issues with index-2 and so on and so forth)

I see three different ways:

- suffix-file.tcl
- file-suffix.tcl
- file.tcl-suffix

What do you think is best?

Daveb's talking about a per-instance mechanism. That also exists today, but only if you know the instance name, which is clunky. However ... the proposed mechanism is also clunky, no?

As mentioned before, I need customizations for package key, for *ALL* instances of a package. I do agree that the whole idea of subsites which came afterwards does not make any sense in this light and should be dumped.

Is there a way to prevent us from having to make apm_package_types objects?

a) Add a supertype to the table
b) Work with package_ids, forcing the supertype package to be mounted at least once.

Both do not appeal to me but maybe someone else has some more ideas on that.

What would be involved in making apm_package_types objects? I remember there was a document somewhere on how to make your package use acs_objects, but I forgot where it is. Anyone? And is it that much work that we should shy away from it?

Here are some ideas:

- Create an object_type package_type which uses the apm_package_types extended table
- add a package_type_id which references acs_objects
- drop the PK constraint on package_key, just make it unique and not null
- create objects for all package_types of the object_type "package_type"

- We do not need to change any existing select scripts as we are adding a column, not taking one away. Or am I missing something here ?
- We need to change any script that inserts into apm_package_types, which means to rewrite the function apm_package_type__create_type. And that should be it.

I would think about the RP later, but what are the reasons that speak against making package_types acs_objects ?

Because I try to collect feedback from the community before I head in any specific direction, especially when it comes down to coding changes into core. And as you can see from the discussion it sparked, my "implementation" would not have been one generally acceptable.

In the past the change I thought off would work when you wanted to change the login screen for users in acs-subsite/lib/login.adp. I managed to make the location of this file a parameter in 5.4 and now you can store that file in a custom package. I did it this way because none of my clients wants the default login.adp, therefore general usefulness is implied.

But what if a client has changed /acs-admin/www/admin/become.tcl to make an additional permission check for special sysadmin privs which they have in their custom application. None of my other clients wants this. It is not generally useful in OpenACS (I'd assume), so the only options at the moment I have is:

a) Make the location a parameter (yet another one?)
b) Write a callback so others can make additional checks if the want to
c) Rewrite their whole handling of permission checks for sysadmins to just use ACS permissions (they would not pay for that)
d) Fork and always remember there is a change in that file when merging new versions from OpenACS
e) Write /www/acs-admin/admin/become.tcl

a-c) Do not make sense.

d) Is something I would like to avoid and be it for the reason that the client could by accident say "update from repository" and overwrite the change.

Doing d) has the benefit that, when a new version comes out and you use a clever merging tool then chances are that you will not run into any problems and still retain your custom changes. At least for a minor change like this. But what if your whole page has changed? Then it might be better to have a custom version of the file and just look at the changes in the OpenACS version and modify if needed manually.

e) Works beautifully (thanks Don for reminding me about that), but only in packages that you mount *once* (otherwise you would have to do it for every mountpoint).

I have seen client installations where a custom package was used and they included the OpenACS functionality. That works as well, but provides a lot of code and makes code maintenance more difficult (as you need to copy files which are not really needed as well, just to make the custom package provide the minimal functionality needed). At least I initially got confused which package is used and mounted when working on that site.

So the idea of Don's appeals to me most at the moment and if there is the time I will probably investigate it a little bit more. For the time being and my immediate needs I am fine with option e), though I would like to come up with a general plan (best practice) on how to do these kinds of customizations / forks you name it.

"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 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 :)

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.