Forum OpenACS Q&A: Correct way to override parameters on installation?

Huge kudos to the OpenACS team on the 5.10 release. I am seeing some amazing features that extend the functionality of these cms in some amazing ways!

I wanted to inquire if there is a best practice for creating our own packages that 'overwrite' existing parameters (and potential procs) in openACS core packages. For example, let's say I want to have rich-text turned on by default when we install a new openACS and turn off a number of the xowiki default parameters. I also want to do this in such a way that separate our custom code from core code to allow for a much easier upgrade path.

I understand that acs-templating will meet many of these needs but as far as 5.9.1 there were some limitations (ie. we still needed to add adp pages to the /www/ folder of xowiki and not our template folder. I also haven't had a chance to look into some of our proc changes that some of our devs usually do.

Essentially, I'm trying to mirror some of my experiences developing in Drupal where we utilize overrides and hooks to modify any contributed packages in our own package without modifying core or vendor packages.

Thank you in advance for your time!

Posted by Gustaf Neumann on
Dear Paul,

many thanks for the nice words.

Let's start with the package parameters: Parametrization can be done already in multiple (too many?) ways.

  • In general, all package parameter can be overloaded in the configuration file of NaviServer (see e.g. [1]). So, every nsd instance might have different settings depending on the configuration file. Overloaded means, that this value is fixed for this instance.
  • In case you want to initialize the parameters differently for some instance, on case use the .xml files (see e.g. [2]), which can be used the set various settings (not only parameters), when a package is installed. It can be certainly customized for certain sites.
  • For the xo* packages, there are further means, site-wide parameters and parameter pages. In xowiki/xowf there are default values, which are used whenever such a package is newly instantiated (i.e., adding such a package to a course, etc.). These are set via the "site_wide_package_parameters".
  • If some of these instances should have a certain combination of parameters set, this can be further refined via parameter pages (which are FormPages (attribute/value pairs with a user interface). With parameter pages one can provide a certain subset of the parameters, on can define access/modification rights to these, and can keep a central place, where one can maintain all such values from a single place.

So, depending on your needs, different mechanisms might fit better.

Concerning overloading/modifying procs. Normally, the best thing would be not having to change the procs, but to provide sufficient parametrization for all needs (which is probably not possible either). When seeing some needs, post these to forums or make feature requests via the bugtracker would be the best.

When you have to overwrite code, it is often useful to define your own separate files loaded after the files from the distro. However, this requires certainly checks, when the overloaded procs are changed, since similar changes are required as well in your modified code clones. In practice this is often easier than doing complex merges. The xo* code supports mixin classes, which allow fine granular overloading on the fly without altering the code.

When altering code is still needed, providing a proper setup of the code repos can ease maintenance significantly. We use git (essentially a checkout of OpenACS from github with local branches), which is a longer story (Maybe Hector can sum this up, when he is back from vacation).

Hope this helps,
all the best


Posted by Paul Babin on

Thank you so much for this detailed response. The .xml file is new to me and looks like exactly what we need. I'll be pouring over this new release over the coming weeks and looking forward to learning about all of the new features.

One of the coolest features I have seen yet is the drag-and-drop file functionality for xowiki working out of the box.

Again many thanks for all your and the team's dedicated work on this project over the years!