[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