HierarchicalGroups-Talk

Summary: Talk page for HierarchicalGroups.

Maintainer: N/A

Users: (View ? / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

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

I just wanted to add my thoughts on this, and sort of try to explain what I'm doing.

My desire for subgroups sort of arose naturally when I wanted to start storing cooking recipes in a group on my personal wiki. That led me to think about how I might structure such a thing. The solution I arrived at was to store a Parent PTV in each page that I'd use in a pagelist to list the children of a given node. This isn't truly hierarchical, and it doesn't alter any group or page name uses, but seems to work for my purposes. Just to show what I'm talking about, I'd have the following on a page:

(:Parent:(Recipes.)Breakfast:)
!! Tossed Salads and Scrambled Eggs

!!! Ingredients
* salad
* eggs

!! Directions
# scramble eggs
# toss salads

Tossed Salads and Scrambled Eggs

Ingredients

salad
eggs

Directions

scramble eggs
toss salads

Then, the Recipes.GroupHeader page includes:

(:pagelist $:Parent={*$:Parent} group={*$Group} name=-HomePage,-*-Talk,-*-Contrib fmt=#parenttrail:)

which gives a prev/up/next trail at the top of each page.

In each section (i.e. "Breakfast"), I include another pagelist in the body:

(:pagelist group={*$Group} $:Parent="({*$Group}.){*$Name}" list=normal name=-Tempate,-*-Talk,-*-Comments,-*-Contrib fmt=#titlesummary:)

This seems to work well for my needs. This is visible at http://wiki.tamaratemple.com/Recipes/HomePage

tamouse March 10, 2012, at 02:40 PM

Talk page for the HierarchicalGroups recipe (users ?).