[pmwiki-users] Hiearchical Groups Proposal.

The Editor editor at fast.st
Wed Oct 18 05:14:46 CDT 2006

Pm said:
>>One outcome of this approach is that it's not possible for a group's
>>"home page" to have a different set of passwords from other pages
>>in the group.

This is a small price to pay for hierarchical groups.  If one wanted a
"homepage" to have a different set of passwords, he would just
designate and use another page in that group for that purpose.  Even a
redirect or include might suffice to grant the extra protection.  Or
keep the page in its own group, and have the other group pages
actually in a subgroup.  There are enough work arounds we could allow

Pm said:
>>If GroupAttributes, GroupHeader, and GroupFooter become page metadata,
>>that would seem to imply that we need a mechanism to be able to
>>edit these metadata.  And presumably we should keep track of
>>the history for these metadata items as well.

I don't know that it is necessary or wise to do this.  It would break
tons of sites, maybe too many to be worth the change.  The existing
system works fine and allows you to keep history etc, with no extra
revisions to core, or complex page formats.  (Ugh--I can only
imagine).  I think we should assume for simplicity's sake (and page
size sake) that only changes to text= will be kept in history.

Stirling said:
>>If this became a major issue I could imagine having a more complex
>>scheme that allowed one to set multiple collections of passwords in the
>>page's metadata, each collection associated with a page selector of some
>>kind. This would allow one to set passwords for 'this page and below' or
>>separate passwords for 'just this page' and 'this page's children', but
>>I'd be reluctant to go down that route. I find the current
>>authentication scheme hard enough to navigate as is.

Agreed that the current scheme is hard enough. The more complex scheme
above would double at least the number of fields on any given group
attributes page, maybe more.  Too complex.  Hierarchical groups will
be a big enough change--we should perhaps avoid changing as little
else as possible to make this work right.

Stirling said:
>>A more general metadata system might be desirable anyway, as there are
>>many things one might end up wanting to cache in a page and I can
>>imagine many recipes that might make use of such a facility.

This immediately brings to mind Pico's great idea of storing things
like data and comments in page attributes.  We should consider both of
these proposals together.  Though I don't want to add groupheaders and
footers to pages, any changes we make to the page to allowing access
to metadata should think ahead to hierarchical groups and recipes like
zap.  For example, I can envision storing form data on a homepage, and
perhaps making it available to any page in the group.  Just an idea...

Jo said:
>>Ideally, metadata would be pages, possibly with a special marker in the
>>page name so PmWiki knows that they don't get meta-metadata.

Separate pages for groupheaders and footers (which should NOT be
inheritable to subgroups). But no to passwords, etc, which should be
inheritable (ie: store in the page).

These are some exciting concepts!  However, I still like the idea of
virtual hierarchies as it may be easier to implement, will probably
break fewer sites, and it offers much more power and flexibility.
There have been no comments on it yet pro or con.  I would be
interested in feedback on it, perhaps in comparisons with Stirlings
excellent idea.  Before we get to set on one direction.  (Though I'd
be happy with either).  Will repost as a separate thread after I fire
this email off.


More information about the pmwiki-users mailing list