version=pmwiki-2.2.2 ordered=1 urlencoded=1
agent=Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
author=Tyrus
charset=ISO-8859-1
csum=
host=98.163.224.82
name=PmWiki.HierarchicalGroups
post= Save
rev=43
targets=PmWiki.WikiGroup,Profiles.Pm,Profiles.JoachimDurchholz,PmWiki.Audiences,Profiles.Feral,PmWiki.MailingLists,Cookbook.Cookbook,PmWiki.WikiTrails,PmWiki.Categories,Cookbook.SubgroupMarkup,PmWiki.HierarchicalGroups-Proposals,Category.PmWikiDesign
text='+This+' page explains why PmWiki doesn't currently use hierarchical or nested groups.%0a%0a!!Pm's Explanation%0a%0aWhen implementing [[WikiGroup]]s I did think for a while about%0aimplementing hierarchical groups but ultimately decided against it for%0aseveral reasons:%0a# It doesn't seem to add any additional power or flexibility%0a# It adds complexity in terms of referencing pages in other (sub)groups%0a# I examined other systems that implement hierarchical groups and didn't like the complications it seemed to impose%0a%0aTo see the first point, and to borrow from the example given, instead of writing [=Animal.Mammal.Canine.StBernard=] one can just as easily write [=AnimalMammalCanine.StBernard=] and get basically the same%0aresults and capabilities.  Or, if we really need separators, perhaps allow hyphens in WikiGroup names and do something like [=Animal-Mammal-Canine.StBernard=].%0a%0a->''I disagree. The group [=AnimalMammalCanine=] has no implied relationship to group Animal, the way [=Animal.Mammal.Canine=] does.'' --Profiles/EvanProdromou%0a%0a->%25Pm%25From a practical view point, how would an "implied relationship" change anything in terms of how pages are rendered or interpreted?  --[[~Pm]]%0a%0a-->PmWiki would "know" the relationship between the [=Animal=] group, the [=Animal.Mammal=] group, and the [=Animal.Mammal.Canine=] group. This affects various functions: group searches (would cover subgroups), renaming (moving a group to a different place would also affect the pages in the subgroups), pagelist generation (again, would include subgroups - good for generating wikitrails that span several hierarchies).\\%0aMany of these issues could be worked around by allowing wildcards on group names in the various context. The ramifications of this approach haven't been well explored yet.--[[~JoachimDurchholz]] May 24, 2006, at 05:00 PM%0a%0a-->''That implied relationship would also enable inherited permissions, so that if a password restriction were placed on the [=Animal=] group, that restriction would automatically carry down to [=Animal.Mammal.Canine.StBernard=].  To handle that with the [=AnimalMammalCanine.StBernard=] style format, you'd have to protect each subgroup seperately.''  Anonymous, May 21, 2007%0a%0a-->Perhaps designing where you cut off groups would make a better difference? i.e. [=Animal.MammalCanineStBernard=] vs. [=AnimalMammalCanine.StBernard=] or perhaps a separate wiki for different main groups. -- I have not looked at farms or such yet -- But, I can see wanting a sub-group just for an event. i.e. Main.Events.Eventa (eventa might have 10 docs) I am guessing events should be its own wiki in a wiki farm? I saw somewhere you could share logins among wiki's?  Patrick, July 4, 2009 %0a%0a->''It would be nice if pages could be defined in a hierarchy (I'd rather say, classified) so that context sensitive menus could be generated. A means for defining additional relations metadata could provide additional menuing for crumbtrail and related links, all automatically generated for each page.'' --pacoit%0a%0aOn the second point, the problem comes from trying to decide what one should do with markup such as "[=Canine.StBernard=]" inside of the "Animal.Mammal" group, especially if there's a top-level group named "Canine".  If we treat [=Group.WikiWord=] links as always being absolute, then there's not much organizational advantage to having%0ahierarchies.  If we allow relative paths, then there's all sorts of room for ambiguity unless even more markup is added to resolve it, and it's possible that someone creating a page in an intermediate subgroup inadvertently changes the target of existing links.  All of which just makes things more difficult for [[Audiences |naive users]].%0a%0a->There's indeed a problem here. Hierarchical file systems solve this by distinguishing absolute paths syntactically (i.e. in Unix they have a leading /).\\%0a--[[~JoachimDurchholz]] May 24, 2006, at 05:32 PM%0a%0a->One of the central problems is that if a name refers to both a page and a group, there are two conflicting intuitions of what's the "current group" on the page. It could be the page itself, or it could be its parent page.\\%0a--[[~JoachimDurchholz]] May 25, 2006, at 03:27 PM%0a%0a->Since PmWiki not hierarchy-compliant, i can't use it on our site. We need at least 3-level hierarchy. Hierarchy on PmWiki is a technical or philosophy problem?\\%0a--Romiras (romiras@sources.ru)%0a%0a>>border="1px solid purple"%3c%3c%0aHello,%0aI would like to point out that Cookbook:Cluster is a very workable solution to this particular problem. It is not a perfect solution in that it is not as closely integrated by default as a core solution would be, however I believe this is the best solution to this problem currently and VERY functional.%0a%0aIn my own case I was having a very difficult time translating to PmWiki's style of content separation; It is in essence simply is not how I work and shoehorning me into that thought process was not, in my opinion, working well. ;)%0a%0aLet me illustrate and let us use the presented example, [=Animal-Mammal-Canine.StBernard=].%0a%0aIn my view the problem with a single level hierarchy, such as the default PmWiki handling of WikiGroups, are simply that there is no coherency between fake levels. For example If I change the GroupHeader in Animal, this is to say [=Animal.GroupHeader=], I would expect that to be reflected in it's children, such as [=Animal-Mammal/=]. This can be accomplished automatically via the [[(Cookbook:)Cluster]] recipe. ([-As well as a style of simplifying links between children and or parents.-]) A similar failing, in my opinion, of this base method is that I expect to be able to easily shift my focus to a parent group. Ye olde [@cd ..@] ;) My modifications to the [[(Cookbook:)Cluster]] recipe alleviates this via a clickable trail that can be included in a page, (I.e. GroupHeader in my personal usage).%0a%0aIn essence with the [[(Cookbook:)Cluster]] recipe the problems with the [=Animal-Mammal-Canine.StBernard=] style of hierarchy become very manageable. I prefer this method to PmWiki's "flat hierarchy" and have had no problems to date and I have only nice things to say.%0a%0aMy personal thoughts are that something of this nature is important enough to '''usability''' to be suitable for an optional CoreCandidate such as creole markup is, however the recipe method works fine as long as we all know about it, and of course can get it to work.%0a%0aMy best regards to you,%0a->[[~Feral]] March 13, 2007, at 11:17 PM%0a>>%3c%3c%0a%0a%0a!!''' Perhaps not the right platform%0aI would have to agree that for some applications or perhaps for some of us that have a mental construct of hierarchical systems that pmwiki is difficult to wrestle with.  I have been searching high and low to figure out how trails, links, and groupings work.  I suppose I assumed I could group within groups.  The result was that links and pages seemed to disappear.  Trails led to places that made no sense and renaming a group disconnected what I thought were children.  %0a%0aReading this says to me that there are ways to change my thought process about relationships but I think I am too old and set in my ways to rethink all of this and perhaps my best solution is to find another platform.  That is not to say the decisions on this platform are not well thought out and work for many (or perhaps most) people.%0a%0aDoes anyone have a suggestion on a platform that would be a good replacement?%0a%0a%0a%0a!!History%0a%0aThis topic has been discussed on the pmwiki-users [[mailing list(s)]] at great length on several occasions throughout 2003 and 2004, and the general consensus seems to be this:%0a%0a* The current one-group-level mechanism is seen as the best (or the least bad) of the available choices%0a* Once a good syntax and semantics for hierarchical groups has been found, we'd like to have it. But we don't want a bad solution here.%0a%0aThe software has been designed such that it could eventually support hierarchical groups via a [[Cookbook]] recipe, if we ever resolve the outstanding issues.%0a%0a%0a%0a!!Alternatives%0a%0aThere are also other alternatives to using the group hierarchies to organize page content -- [[WikiTrails]],  [[Categories]], and WikiFarms can often resolve the issue with more power and flexibility than what WikiGroups can do.%0a%0aThe [[Cookbook.SubgroupMarkup]] recipe adds one level of subgroup to the current wiki structure. For many problems, this may be sufficient. It introduces [=[[,subpage]]=] markup to designate a subpage of the current page. The subpages of a particular page form a subgroup of the current group. For example, [=[[,proposals]]=] and [=[[,discuss]]=] are pages in the PmWiki.HierarchicalGroups subgroup of the PmWiki group.%0a%0a!!Proposals%0a%0aThe issue has been discussed on and off on the mailing list. Summaries of proposals, conceptual backgrounds, and other discussion results can be found on the [[HierarchicalGroups-Proposals]] page.%0a%0aCategory: [[!PmWiki Design]]%0a
time=1246720118