[pmwiki-users] hierarchical groups, revisited

Joachim Durchholz jo at durchholz.org
Sat May 27 05:52:35 CDT 2006

John McGinnis schrieb:
> The formatting was screwed; I hope the following correction is what you
> meant:
> |     Yes. Thanks for the clean up.


could you please, please, please reconfigure your Outlook to
a) mark quoted text by adding another > marker and
b) *not* mark your added text with a | marker?

Oh, and
c) that is doesn't add an empty line after every quoted line?

The way your Outlook is configured now plays havoc with everybody else's 
mailer; I have to manually reformat all quotes for your mails to make 
them even remotely readable.
(A good first step might be switching to "plain text format". Most mails 
are in plain text anyway; all the fancy formatting isn't standardized 
and secured well enough to be useful for many recipients.)


>> Actually that's independent of the hierarchy discussion. You want 
>> aliases; redirects solve that problem. (Well, to a large part at least; 
>> people following a virtual hierarchy will find themselves in another 
>> group than they expected, but hey, that would happen even if the aliases 
>> were not faked by redirects.)
> I would fully expect that hierarchy could/would be part of a group 
> albeit virtual.
> I guess the piece I am missing is what you envision for a 
> redirect/alias. If I look at a wiki trail today, in many aspects it is 
> a hierarchy of unlimited depth but limited to a breadth of one; ie. that 
> single thread of pages. As far as I can tell it lacks any reference to 
> aliases.


I'm still not sure what you're aiming at, and how it relates to 
hierarchical groups.

I see aliasing orthogonally to hierarchy. When (if) hierarchies are 
introduced in PmWiki, you'd be able to set up two hierarchies, and have 
the leaf pages of every hierarchy alias leaves of the other hierarchy. 
If hierarchies never make it into PmWiki and you stick to the various 
ways of faking hierarchy that have been discusses, you can still make 
the leaf pages into aliases of the other hierarchy.
This would work regardless of whether the aliasing is done via redirects 
or via some aliasing mechanism integrated into PmWiki's core.

So this seems to be a separate discussion to me.

(Or am I misunderstanding something here?)

>> Group-specific templates. (If would be nice if these were wiki pages, 
>> but I see no special difficulties other than that.) With redirects, that 
>> wouldn't help with the leaf pages, of course.
> Group templates would be a good approach and has continuity with 
> other PMWiki ideas like pagelist templates.

They already exist. Simply configure a different skin depending on what 
group is current in config.php.

E.g. say

if ($Groupname == 'MySpecialGroup') {
   $skin = 'myspecialskin';
} else {
   $skin = 'standardskin';

($Groupname is probably the wrong variable name to check, there's a 
Variables page somewhere in PmWiki that documents the PHP variables that 
are useful for config.php.)

>> Whatever a proposed system does: if it needs this kind of precedence, 
>> it's doomed. Such systems have the property that adding a page can 
>> change the interpretation of links in unrelated pages; I don't even want 
>> to imagine the ensuing madness.
> Interesting, and point is noted. However, it would seem reasonable 
> that if Main/PageA has a given defined %define…% page attribute. And 
> say a hierarchical group Virtual is created such that Main/PageA is now 
> aliased also as Virtual/PageA; that a given %define% of the same name 
> in Group Virtual should overlay that of Virtual/PageA. A Main/PageB 
> would not be affected nor would Main/PageA. Being able to overlay in 
> this manner would have great power in page design.

There would be no conflict in this case. But there would be many 
potential conflicts.

CSS is a classical case. It does have a lot of precedence rules, and it 
is *very* difficult to predict which rules will actually apply to some 
given tag for even moderately complicated setups. Things get far more 
complicated when trying to understand somebody else's CSS.

Now with CSS, it's rare that I have to find out what defaults were 
provided by somebody else. In a wiki, that's the norm, so the problem is 
Imagine a lot of well-working defaults, and somebody introduces a new 
setting somewhere up in a hierarchy. It will affect all the pages lower 
in the hierarchy, including many that he doesn't even know about (think 
20,000-page wikis), and likely breaking a few of them.

Actually since inheriting settings down hierarchical groups is a very 
desirable feature, that's a strong reason to distinguish between normal 
hierarchy and aliased hierarchy, and that properties of whatever kind 
should be inherited along just the main hierarchy, not the aliased ones. 
(In the filesystem analogy, this would mean we'd be using symlinks, not 

(I didn't understand the last section, partly because it was stretched 
over several pages by the empty lines inserted by Outlook and I was too 
lazy to reformat a text where I didn't know whether such an action would 
really help me understand it. Sorry for the inconvenience of my ignorance.)


More information about the pmwiki-users mailing list