Wiki Meta Structure (Was: Re: [Pmwiki-users] Easily Hackable?)

H. Fox haganfox
Sun Apr 4 13:30:32 CDT 2004


Fabio Reis Cecin wrote:
> On 3 Apr 2004 at 23:32, Pmwiki-users-request at pmichaud.com wrote:
>>(...)
>>I think authorization really has been done best when it includes both groups
>>(of users) and hierarchy. My favorite model has been AFS, which applies
>>rights to directories rather than files. In PmWiki's world, this would be
>>similar to binding the rights to the groups (of pages) rather than to the
>>files. In a way, this is a cousin of the "all-or-nothing" approach, but not
>>quite so easy to solve. The need for page-level control fades if you allow
>>groups to have a hierarchy (groups (of groups (of groups (of pages)))).
> 
> Maybe this is a deviation of the original discussion but I'll post anyway:
> 
> I was thinking for a long time that nested groups are needed in PmWiki to
> solve a problem I'm curently having. But then the solution (NOT needing
> nested groups) just struck me (while I was typing a reply stating that
> nested groups would be a great addition :-) :
> never see dates again in the wiki text.
> [...]
> But, of course, the solution is to keep the GROUP NAMES complex. Imagine that the
> group name is the "full path" of your pages. So, instead, I should have created groups
> of pages named like this:

A few days ago on #pmwiki dbcooper was showing off a spectacular 
auto-collapsing SideMenu that allowed an arbitrary hierarchical 
structure to be created in the menu, irrespective of structure of the 
actual pages.  A Wiki Meta Structure like this would free the Wiki 
Administrator from being forced to use the structure as-installed.

I think this approach addresses another important problem with a 
group/subgroup/subgroup/page structure: Some pages (or groups) might be 
equally suitable to have in two or more places.

The collapsible menu was just based on a list, which seems like a great 
way to represent a meta-structure.  This way the sky's the limit in a 
very Wiki-esque sense and 'refactoring' would be as simple as modifying 
the list.  Example:

* Beverages
** Alcoholic Beverages
*** Beer
**** Commercial Beer
***** Yellow Fizzy Stuff
***** Craft Brews
****** Label Art
**** HomeBrew
***** Recipes
****** Coia Stout
etc...

* Hobbies
** Cooking
*** Home Brewing
**** Equipment
**** Recipes
***** Label Art
****** Coia Stout Label
**** Web Sites
*** Wine Making
etc...

*Art
** Beer Label Art
*** Commercial Beer Labels
*** Home Brew Labels
etc...

An extra bonus would be if wiki trails cold traverse the meta structure, 
where the "previous page" and "next page" would be within the context of 
the current location in the side menu.  But I digress...

My point about wiki meta structure is more abstract than just a side 
menu.  Such a structure might be useful in many ways, possibly including 
the security context discussed in the original thread.

Hagan




More information about the pmwiki-users mailing list