Recent Changes - Search:

Cookbook

PmWiki

pmwiki.org

HierarchicalGroups

Summary:Information about Hierarchical Groups
Version:N/A
Prerequisites:N/A
Status:N/A
Maintainer:N/A
Categories:Hierarchy, PageNaming

Questions answered by this recipe

How come PmWiki doesn't have hierarchical groups? Are there any recipes that provide them?

Description

Information about Hierarchical Groups

Here is a brief table comparing/contrasting Hg/Cluster as both are very similar recipes, and use almost identical syntax:

Hierarchical Group FeaturesHgCluster
Hierarchical groupfooters, headers, attributes, css, and configYesYes
Name-based clusteringNoYes
Subgroup, Subname, and index page variablesYesYes
Built in Group Titles page variablesYesYes
Absolute, Relative, & Descendent Link shortcutsYesYes
Automatic Bread Crumb markupYesYes
Bread Crumb AliasingYesYes
Generalized hierarchical page variablesYesYes
Built in CleanUrls capabilityYesNo
Link prefixing & virtual wikisYesNo

Definitions and notes:

Hierarchical groupfooter, headers, attributes, css, and config
Causes these various features of group Kingdom to be passed down to Kingdom-Animal-Canine except where specifically overwritten at a lower level.
Name-based clustering
Pages can be clustered as well as groups. Kingdom-Animal-Canine.Dog and Kingdom-Animal-Canine.Dog-Terrier can be part of the same cluster.
Subgroup, Subname, and index page variables
Uses notation like $g3 and $n2 to refer to the various subparts of the page name. $g0 and $n0 are an index of how many parts there are in the group or name respectively.
Built in Group Titles page variables
This feature gives you a $grouptitle page variable for use on your page. In Hg you can set up a single Site.GroupTitles page and use text variables to define group titles (if not set, Hg returns the last subgroup). Cluster look for titles in various group locations according to rules in the GroupTitle recipe.
Absolute, Relative, & Descendent Link shortcuts
Introduces special shortcut notations to the links markup (*, ^, -) that make it easier to refer to other link locations in the pagename hierarchy.
Automatic Bread Crumb markup
Allows you to put a simple markup on your page (or skin) that will produce a pretty, clickable breadcrumb. ie: Kingdom > Animal > Canine. Cluster includes a special function to simplify inserting the breadcrumb into the skin. In either you can turn on or off inclusion of the name in the breadcrumb.
Bread Crumb Aliasing
In Hg, a Site.HgBreadCrumbs page is used to control how each element in the breadcrumb display appears, whether or not it appears, or to insert any alternate markup desired--using simple text variables. In Cluster, the breadcrumb can be set to display either the subgroup name, or the subgroup titles.
Generalized hierarchical page variables
Allows you to create an unlimited number of hierarchical page elements. By default Hg has $SideBar and $SideMenu. Cluster has $ClusterSideBar and $ClusterRightBar. Generalizing this allows you to easily create additional elements in your config file.
Built in CleanUrls capability
This automatically changes how links appear from Kingdom-Animal-Canine.Dog to Kingdom/Animal/Canine/Dog. Can be combined with Url rewriting to eliminate the pmwiki.php?n= part. It is disabled by default in Hg.
Link prefixing & virtual wikis
Suppose for example you had groups like Profiles-Id-Caveman and Profiles-Id-Kathryn. By setting a link prefix in the Profiles-Id config page, Caveman and Kathryn would both become virtual top level wiki's with links like [[Hobbies.PmWiki]] automatically being invisibly converted to [[Profiles-Id-{$AuthId}-Hobbies.PmWiki]], and links like [[PmWiki]] being converted to [[Profiles-Id-{$AuthId}.PmWiki]]. There is an escape sequence for links to other parts of the site.

Contributors

Comments


I prefer using single site config pages for group titles and breadcrumb aliasing. It makes maintenance much easier. More flexibility, and no need to constantly edit config files. Plus, because these are text variables, they can be used elsewhere on your site. Caveman March 18, 2007, at 06:47 AM


I prefer using page-variables, because one has all the power of PmWiki's page-variable system.
I don't want to change the interpretation of pagenames, because (a) it seems to be more trouble than it's worth and (b) I can get half-way with "pretty" URLs by using Apache rewrite rules.
I don't do link prefixing because I don't see the point; one could use a page-variable instead, and that's simpler because it uses PmWiki's existing mechanisms.

Kathryn Andersen March 18, 2007, at 03:16 PM


Mostly just to note that I have spiffed the comparison table and added notes regarding my changes to cluster;

However, since I am editing anyway I would like to take this opportunity to thank all involved. The way I work I NEED hierarchies, lol, and doing without was gnawing on me. This said I would like to take this opportunity to ask about Link Shortcuts, specifically of what use is the '*' relative shortcut? I do not understand why this notation exists nor do I see any reason to use it.

Thank you kindly,

Feral March 19, 2007, at 03:11 AM

If you are on page group Kingdom-Animal-Canine.Dog, *.Home? will link to Kingdom.Home, **.Home? will link to Kingdom-Animal.Home. The ^ markup is relative to the current group (one or more levels up), and the - markup links to the current group down. ~Caveman

Ah, alright, thank you Caveman (=

I think what throws me the most with it is it is very misnamed. '*' is certainly not absolute in my train of thought, for instance if you move the page to a different tree then '*' does not point to the same place any longer, thus it is not absolute, but rather a spacer. Once that thought hit me upside the head I began to see a few uses for it. (=

If it means anything my I tend to prefer to keep all of my data together, as I have found it simply works better when shifting things about. Something of which I do rather often ;) One of the reasons I prefer PmWiki to other solutions is one disc file contains all I need to know about the page; This makes manipulations much less complex than other methods. As such I tend to prefer local solutions rather than one spot for config options. This is not to say that centralized configs are not desirable by any means but for something like the name of a bread crumb element it just strikes me that keeping that data with the page is more logical, and thus I prefer the $Title solution. *smile* As long as it works it is all good! ;)

Best regards and happiness,

Feral March 20, 2007, at 08:40 AM

The term "CleanUrls" is actually quite confusing, because the CleanUrls recipe is completely independent of this -- one can use CleanUrls with Cluster, it's just that Cluster doesn't create or interpret URLs in the form of Group/SubGroup/Page

You do not need to use the CleanUrls recipe to get this effect in Hg. Hg offers an alternate, and in many respects simpler way to do cleanurls. Just click on one config settings. It works on systems (like mine) where you cannot normally get CleanUrls to work, and it's easy.
Interestingly I have found no need for a CleanUrl style; I find I process the group separator in the same manor and actually prefer to see the actual group name in the URL; I do, however, have the advantage of being a personal wiki and not having to worry about users (= -- Feral March 20, 2007, at 08:40 AM

Edit - History - Print - Recent Changes - Search
Page last modified on May 27, 2007, at 03:36 AM