[Pmwiki-users] Re: Why groups?

Christian Ridderström chr
Sat Jun 12 11:20:24 CDT 2004


On Fri, 11 Jun 2004, Patrick R. Michaud wrote:

> On Thu, Jun 10, 2004 at 12:41:57PM -0600, Christian wrote
> > 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).
> 
> Yes, we can discuss it this way.  For the original PmWiki I chose the
> word "groups" because UseMod wiki was already using "subpages" to
> mean something different than what I was doing, and I felt that
> "groups" was a more appropriate term anyway.  In a full hierarchical
> system it may indeed make more sense to discuss "pages" and "subpages".
> I think I'll try phrasing things that way for a while.

Maybe the term 'parent' and 'child' would be easier for normal people, 
i.e. a page may have an arbitrary number of children (child page). 

> Also, in any discussion of hierarchical pages I think that people
> making proposals need to also address the issues of passwords,
> permissions, and group (subpage?) headers and footers and not just
> assume that they will "just work" the same as in the current model.

Good point. I'm listing the issuses again, are there any more issues?

* Passwords - how to specify the password for a page(s)
* Permissions - how to specify which users are allowed to edit etc
* footer/header - how to specify a common header/footer
* sidebar - how to specify a sidebar

> For example, what headers/footers get processed by a subpage that
> is several levels down a hierarchy?

How would we specify a header for subpages anyway? If we have a page
called 'A', we could say that the page 'A/GroupHeader' defines a header
for 'A' and any children of 'A'. So 'A/B' would take the header from
'A/GroupHeader'. This is just like PmWiki 0.6 so far. Now what if page 'B'
has a child called 'C' (i.e. 'A/B/C'). I can think of several solutions:

* Use 'GroupHeader' from same level if it exists, otherwise don't use a 
header. This means you don't inherit headers, and would have to create 
'B/GroupHeader' with the text [[include:/A/GroupHeader]] in order to use 
the same header as the parent page.

* Use 'GroupHeader' from the same level if it exists, otherwise check the
level above recursively. This has the consequence that if '/GroupHeader'
exists, it will create a "default" header for all pages. For example, if
'/A/GropuHeader' doesn't exist, the header is taken from '/GroupHeader'.
In order to prevent this you would have to create an empty 
'/A/GroupHeader'.

* We could control if the header should be inheritable by using a 
directive, i.e. writing '[[dont inherit]]' to '/A/GroupHeader' would make 
it so that child pages don't inherit the group header.

I think I like the second behaviour, espeically being able to create 
a default header (or sidebar etc) for the entire site.

Another neat thing with child pages that I just realized is that it allows
us to easily define 'characteristics/attributes' of a page. The child page
'A/GroupHeader' is one kind of attribute, and if we wanted to be able to
specify words that shouldn't be interpreted as links, we could do that by
writing the words to a page called 'A/NotWikiWords'.

> And, a I have a big comment about having "pages at the top level"--
> i.e., pages that aren't in a group or that are not a subpage.

> In my early experiments with wiki--before I added WikiGroups--one
> problem I found was that authors, especially new authors, don't tend to
> think in terms of how pages should be structured in the long term.  

I think this is a separate problem (and a very difficult one at that). I'd
even argue that you preferably shouldn't have to worry too much about the
long term structure when you just want to write a simple page. To be able
to worry less about this, we'd need better functionality to re-structure
pages afterwards though.

> Thus, in a page+subpage model, a *lot* of pages will tend to be created
> at the root level, because many authors are just going to want to create
> a link to "SomeNewPage" without considering if the new page is
> subordinate to the current one (in which case the link should be written
> ./SomeNewPage).
> Worse, many authors talking on different topics will be putting new
> pages at the root level, so that when it becomes clear that some sort of
> page-regrouping is needed, disentangling the sets of related pages from
> each other can be a real task.

To be honest, I'm not sure it's such a big problem if there are many pages
at the root level. In fact, at wiki.lyx.org I'd probably preferred it if a
lot of pages were at the root level (most new pages would be about LyX
anyway). However, there's definitely a need for a tool that helps you
restructure the mess after a while. Something that lets you "move" a page
in the tree and have all links automatically be changed. I guess this
should be in a separate discussion though (but I hope we can design PmWiki
2.0 so that something like this is feasible).

> One might propose simply disallowing page creation at the root level...
> but then how does an author create a new "group" (a space in the hierarchy
> where authors can attach new subpages)?

Well, you could simply use a special command to create a new page at the 
root level. But I have a IMHO better idea:

A user is editing the page '/A/B' and he wants to create a new page so he
inserts "[[C]]" and save the changes. This will render as "C?"  since
'/A/C' does not exist and the user then clicks on "C?". He is now shown an
edit form for a new page, where there's in addition to the edit form
(above it for instance) also something like this:

	Select page location:

	[X]	/			[ ]	/
		`-- A				`-- A
	    	    |-- B			    `-- B
		    '-- C				`-- C

	[X] Automatically modify link on previous page if necessary

The user can now visually see where his page will end up, and also choose 
it's placement. Additionally, if he chooses a different location than 
what he initally wrote, the link on the previous text will be 
automatically modified.

> BTW, this is exactly the reason why, when creating WikiGroups, I created
> a "Main" group rather than letting pages live in a space outside/above
> any group.  It was just far easier to say that all pages exist in a 
> group, and a group called Main is a default group but is not "superior" 
> (in terms of headers, footers, passwords or any sort of hierarchy) to 
> other groups.

I can see that the implementation is easier, but I do think that main is
"superior" today because it's the only group that contains
'AllRecentChanges' etc, i.e. stuff that's about the entire wiki site.

/Christian

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





More information about the pmwiki-users mailing list