[pmwiki-users] Proposal 2: Virtual Hierarchical Groups

[Kathryn Andersen]

On Wed, Oct 18, 2006 at 06:24:05AM -0400, The Editor wrote:
> 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...

There are several problems with this.
(a) Categories are just another group, that happens to have special link
syntax.  The listing of category pages is done with pagelist.  So adding
this additional burden to this particular group doesn't make much sense.
That isn't to say that the idea of a taxonomy per se is doesn't make
sense, it's just that linking the implementation of it with the Category
group seems overly complicated from an implementation point of view; it
isn't the same concept as a Category.

(b) As has already been pointed out, what do you do when a page belongs
to more than one taxonomy?  How do you resolve conflicts?
 
> 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.

But categories are *implemented* with pagelists.  No, this makes the
whole thing too complicated.
 
> 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.

SomeGroup.Taxonomy?
 
> 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...

Again, too complicated, adding a burden to Category which is really a
different concept: taxonomy.
 
> 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'm not so sure that your assertion that it would be easier to use in
PmWiki is really justified.  If it was tough to get a handle on it
conceptually in Drupal, wouldn't it be just as tough to get a handle on
it conceptually in PmWiki?

A hierarchical tree structure is nicer, simply because everybody
understands what a tree structure *is*.

Kathryn Andersen
-- 
 _--_|\     | Kathryn Andersen	<http://www.katspace.com>
/      \    | 
\_.--.*/    | GenFicCrit mailing list <http://www.katspace.com/gen_fic_crit/>
      v     | 
------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere
Maranatha!  |	-> Earth -> Sol -> Milky Way Galaxy -> Universe