[pmwiki-users] Proposal 2: Virtual Hierarchical Groups

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


Here's a repost of my earlier suggestions for hierarchical groups
based on categories.  It may take a second to wrap your thinking
around the concept, but if you can, you will realize it offers
tremendous flexibility and power--something no pagenaming scheme could
ever offer.  In the interest of the great future flexibility of
PmWiki, I'd recommend a bit of thought in its consideration.

Cheers,
Caveman

_______________

My suggestion is to go back and analyze why we want hierarchical
groups.  To me it seems the reasons break down into a couple general
areas:

1) To set attributes for multiple groups at one time (by setting
something in a super group, and have it apply to all the the sub
groups under it). Similarly to do the same things for local.config
files. One file controls config settings for all the subgroups.

2) To be able to specify in pagelists and searchboxes whole sets of
groups (by saying search such and such super group and all the
subgroups are automatically included).

If there are other reasons, I'd like to consider them because I have
an idea, based on my experience with Drupal that could meet these
needs.  Something they called taxonomy.

Instead of having real "hierarchical groups", they used virtual groups,
with a complicated scheme we could do much better at
with categories.  If there was a way to define attributes for
categories (how about Something.CategoryAttribute?action=attr) or the
like, and then apply those attributes to any page with that category
tag, you could easily create hierarchies with great flexibility and
power (ie, pages could be in multiple groups, and some pages from some
groups could all be linked together, etc). After all, Categories are already
hierarchical--in fact more flexible...

You could do the same thing with local config files, by calling them
Category.Something.php, or whatever.  Those settings automatically
apply to all the pages connected to that category. Imagine setting a
config file called Category.Form.php with ZAP enabled.  Then just put
a [[!Form] on a page and it works.

As far as pagelists and searchboxes, it could also work by setting a
search criteria to category=whatever (like we do groups).  Maybe it
can already do this. Don't know. Of course we would want the searching
of categories to include sub-categories, wherever we place categories in
categories.  etc.

Additionally, to really make this useful, there should be a way to set
a whole group to a category, perhaps by creating a page called
SomeGroup.Category, where every page in that group is automatically
considered as being in all the categories listed on that page.  (Or
perhaps could use a groupheader/groupfooter). This would allow you to
string multiple groups together very quickly.

It might also be nice to have an optional invisible markup for categories,
where you don't want the link showing up.  Again, maybe there is one, I
don't know...

I know Categories are already hierarchical, but as is probably don't work
the way described above. On the other hand, it might be something that
could be developed fairly easy without having to mess with the current
page naming system.  As PmWiki can already do virtually anything the
average site admin wants, it follows that those clever enough to come up with
special enough applications that require a hierarchical system could
learn how to use categories as described above easily enough.  But
more importantly, the above kind of system would be far more flexible
and powerful than any rigid pagenaming scheme.

(Note this can be imposed on top of existing site.  To use a proposal
like Stirlings, I'd have to rename hundreds of pages to create the hierarchy
affect).

There may be some things I'm not seeing, but thought I would throw
this out, as it could work beautifully.  Drupal does some amazing
things with it's taxonomy (dynamic menubars, forums, permissions,
etc.), but it was tough to get a handle on it conceptually.  With
PmWiki, on the other hand, it would be far easier to use, and much
more versatile.  In fact combining the power of something like Drupals
taxonomy with PmWiki's innate flexibility would give us more
possibilities than we can imagine at this point in the game.

I'd really like to see us work towards developing that kind of
potential.




More information about the pmwiki-users mailing list