[Pmwiki-users] Re: Why groups?

Christian Ridderström chr
Sat Jun 12 12:07:45 CDT 2004


On 11 Jun 2004, John Rankin wrote:

>     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?

Yes. (But I'm not sure what the point is of confusing us with a poor 
explanation).

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

I don't agree here. If we are looking at this page (illustrated using a 
tree):
	/
	'-- A
	    '-- B
		'-- C

and the base URI of the site is http://pmwiki.org, the URI could be:

	http://pmwiki.org/A/B/C

So I think '/A/B/C' should be the path to this page, and I also think that
how we link to pages should resemble what the user sees at the URI.

(Btw, it's probably a good idea to show the tree view at the top of the
page so that the user easily can see "where" in the tree he is at the
moment).

> 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.

I think that's only true if you don't have a visual illustration... (and
talking about page+subpages doesn't help I suspect, parent/child is a
better metafor in this case).

> So my 5? (we don't have 2? any more) are that PmWiki stick with
> groups.
[snip]
> 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

I'd suggest using doing the design using a tree paradigm, but optionally
(or by default) disable certain features so that a group+page structure is
"faked". Hopefully this should be rather simple, and initially only
functionality of parent/child that is needed to fake group+page would have
to be implemented. The faking would involve things like how page links are 
resolved, prohibiting the creation of pages at the root level and allowing 
implicit creation of the group page (when creating a new group).

But to be honest, I have this loose idea in my head that I'd like
something even more powerful/flexible than a tree structure. I'll write 
about that in a different post though.

/Christian

-- 
Christian Ridderstr?m                           http://www.md.kth.se/~chr





More information about the pmwiki-users mailing list