[pmwiki-users] hierarchical groups, revisited

[John McGinnis]

Jo,

 

 

 

The formatting was screwed; I hope the following correction is what you

meant:

 

|     Yes. Thanks for the clean up. 

 

> Cars  . Buick . Electra

>               . LaSabre

>               . Lucerine

>       . GMC . Tahoe

>       . Chevy . Camaro

>               . Caprice

> 

> But now I want to have an overlay like this:

> 

> Cars . Full Size . Electra

>                  . Tahoe

>                  . Caprice

>                  . (Entries from other car mfrs)

 

You can set that up by creating the leaf pages as redirects to the standard
pages.

 

> Presumably one can derive both hierarchies without regenerating all 

> the supporting pages. Worse yet, entries GM, Buick, GMC, Chevy, and 

> Full Size should be assumed to be wiki pages as well without any group 

> dependencies derived from the prior hierarchy.

 

Solved by hierarchy.

Well, you'll have CarsByManufacturer and CarsBySize on the root page of each
category (and most likely these won't be root pages but part of some larger
hierarchy). But I think you can get what you want.

 

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.

 

 

>     * Attribute inheritance (or not, user option) to child from parent.

>       The page layout for example could be inherited from Full Size

>       rather than from Buick for the page Electra.

 

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. 

 

>     * Hierarchical references are independent of the usual page syntax.

>       I think it should be inherent that in referencing the pages one is

>       not making a normal wiki page reference. Something like [# ? #]

>       than [[../<some page>]]. Visual inspection should tell the author

>       this is not a relative link.

 

Actually I think it should be the other way round: hierarchical references
should be part of the usual page syntax (whatever "usual page syntax" will
be at that point).

I may be misunderstanding what you mean with a "hierarchical reference".

 

 

|     Ok. 

|

|     [[ standard relative link ]]  

|     #[ hierarchical absolute link ]# (changed this as I noticed that fmt#=
templates are using [[# currently.)

|

|     The writer knows at a glance a couple of things. The link is part of
an absolute tree structure. That, if |developed, Group level attributes and
possibly page directives might be over ridden by a virtual group template. 

 

 

>     * Precedence. I would hazard that if an existing page is included in

>       a hierarchy that the preference would be that in the event that

>       there are page directives that conflict, that the directive from

>       the hierarchy wins.

 

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. 

 

>     * Hierarchical definition would appear in Search and (:pagelist:)

>       results like any other group:pages.

 

Again, I think I don't understand what you meant when you said
"hierarchical".

 

|     Doing a search on either respective hierarchical Group would yield:

|

|GM/

|  Buick/

|    Electra

|    LaSabre

|    .

|  GMC/

|    .

|  Chevy/

|    .

|

|FullSize/

|  Electra

|  Tahoe

|  Caprice

|  (Entries from other car mfrs)

  

 

|And I can understand why Pm held off on this! The ripple effects as I think
about it are exponentional in scope.

 

 

Regards,

Jo

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20060526/3d9dbd38/attachment.html