[Pmwiki-users] Why heirarchy?

John Rankin john.rankin
Mon Oct 25 15:10:03 CDT 2004


On Tuesday, 26 October 2004 6:00 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
...
>> However, one shouldn't lose sight that farm applications would remain
>> basically be a workaround for pmwiki having such a limited hierarchy.  Kind
>> of a like a kludge to workaround a generic shortcoming...  Seems fixing the
>> shortcoming would be more appropriate and then the kludge actually can be
>> developed from the perspective of offering a useful feature,
>not a kludge.  
>
>*sigh*  PmWiki doesn't have and has never had a "hierarchy", much less
>a limited one.  (Unless you're counting a single level of groups+pages
>a 'hierarchy'.)  
>
>What you're calling a "shortcoming" is to many of us a desirable feature, 
>so to claim that the WikiFarm approach is a "workaround" is to 
>assume that hierarchies are inherently superior to wikigroups, which 
>hasn't been demonstrated yet.  As I painfully discovered while trying 
>to prototype an implementation of Christian's proposed hierarchical syntax 
>over the weekend, WikiGroups are *not* just simple subsets of hierarchies
>or a one-level hierarchy...they're in fact a different
>structure.
>
>Pm

Dredging my memory, isn't a group a set? With the constraint that
a page can only be a member of a single set? Or possibly, since a
group can have attributes, like those defined on a GroupAttributes
page, or a local/Group.php file, it's a namespace.

Certainly, it's unhelpful to think of the Group.Page structure as 
a 'limited hierarchy'. A set is just a set -- it's not good or bad,
right or wrong. Rather, it's either useful, or not. For this particular
problem, I'm thinking that simple subpages may be all theat's required,
not a full-blown hierarchy. These are in principle ridiculously
easy to implement in PmWiki 2.

-- 
JR
--
John Rankin





More information about the pmwiki-users mailing list