[Pmwiki-users] Why groups?

[John Rankin]

On Friday, 11 June 2004 2:53 AM, Christian Ridderstr?m <chr at home.se> wrote:
>Hi
>
>I still haven't had time to read (and understand) all the mails on 
>hiearchical groups, but since I just had a thought I want to write it down 
>before I forget it.
>
>While reading some of it, I wondered why we have groups at all... why must 
>we say that a "group can contain subgroups". Couldn't we instead talk 
>about this as a page having subpages? The pages would then be organized as 
>a tree (or many trees). 

This is the approach some other wikis take. See for example:
http://tavi.sourceforge.net/TaviSubPages

Note that the convention appears to be:

    SomePage is a reference to a 'root' page

   /SomePage is a reference to a 'sibling' page (ie one with
             the same parent as the current page)

   ThisPage/SomePage is a reference to a 'child' page (ie one
             below ThisPage in the hierarchy)

And some wikis say that /SomePage is a reference either to a sibling or, 
if the current page is a root page and hence AnotherPage is the sibling 
(and another root page), then /SomePage becomes a child of ThisPage. 
So on a RootPage, /SomePage is a child of RootPage and SomePage is
another root page. On RootPage/SomePage, /AnotherPage is a reference
to RootPage/AnotherPage. Confused?

If PmWiki goes down the tree route, it oought to adopt the same markup
convention used in other popular wikis.

But I find groups much easier to learn, use and explain than trees.
The discussions on the list have rather reinforced the idea that
trees are conceputally simple, but hard to get one's head around in
practice, especially for casual users.

So my 5? (we don't have 2? any more) are that PmWiki stick with
groups. But it could offer trees as an option in which case
you are right, we should forget about groups and sub-groups and
just have pages and sub-pages. And advice to new users would
probably be along the lines of: unless you know why you need
pages and sub-pages, stick with groups and pages. Your authors
will thank you for it.

My proposal would be:
- stick with groups and pages for 2.0, but don't do anything
  to prevent pages and sub-pages being an option

- perhaps support pages and sub-pages as a local customisation
  in the Cookbook, which appears to be what Jason is doing

- *don't* abandon groups and pages in favour of pages and 
  sub-pages

>[snip]
>
>/Christian
>
>-- 
>Christian Ridderstr?m                          
>http://www.md.kth.se/~chr
>
>

-- 
JR
--
John Rankin