[pmwiki-users] Hierarchical permissions

[Patrick R. Michaud]

On Thu, Feb 01, 2007 at 07:17:08AM +1100, Kathryn Andersen wrote:
> On Wed, Jan 31, 2007 at 07:05:08AM -0500, The Editor wrote:
> > It could be rewritten however (a bit of a pain) to include if it
> > exists Kingdom.php first, then include Kingdom-Animal.php and then
> > Kingdom-Animal-Canine.php third, each one overwriting any settings in
> > earlier ones.  This might be more what people expect, and makes some
> > things easier.  That is, with the current system you have to repeat
> > config settings in child config files.  
>
> Yes. the latter is what I would have expected/hoped for with
> hierarchical groups, otherwise there doesn't seem much point, since you
> don't gain from higher-up settings if you have to repeat them for every
> lower-down config file.

It's not true that config settings have to be repeated in every
lower-down configuration file -- it's easy enough to do with
include_once().  For example, to have Kingdom-Animal-Canine.php
start with Kingdom-Animal.php's settings, place the following
at the beginning of Kingdom-Animal-Canine.php:

    include_once('Kingdom-Animal.php');

There's a strong reason why PmWiki loads the child configurations
before the parent ones, and that's because it's far easier to
prevent something from loading/happening than it is to "undo" the 
effects after something has loaded/happened.

For example, suppose I want to load a customization in
every page in the XYZ group except for XYZ.MainPage .  If XYZ.php
is loaded before XYZ.MainPage.php, then I have to either put
code into XYZ.php that says "perform the customization except for 
XYZ.MainPage", or I have to figure out some code in XYZ.MainPage.php 
to undo the effects of any customizations that were made in XYZ.php.

However, if XYZ.MainPage.php loads first, it has a chance
to make additional configuration settings before XYZ.php
is loaded, including the possibility of avoiding the
customization altogether.  And a single include_once()
statement can get the other behavior.

(This is especially true when using SDV()  (set default value)
to set configuration variables only if they aren't already set.
If the per-group customization is done first, then the
per-page customization cannot specify defaults but can only
explicitly override already set values.)

Pm