[pmwiki-users] Proposal 2: Virtual Hierarchical Groups

[Crisses]

>
> 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...

Maybe too flexible.

If one CategoryAttribute defines that Joe has access to a page --

another Category2Attribute defines that Joe does NOT have access to a  
page --

and a page belongs to both categories --

How do you decide which has precedence?  Does Joe see the page or not?

> 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.

Another problem with this is that someone can put [[!Form]] on say  
the SandBox page and create forms -- that may be a breach of security.

> 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.

Right now it works through searches for links to the Category page.   
So yes.

> Of course we would want the searching
> of categories to include sub-categories, wherever we place  
> categories in
> categories.  etc.

Which makes it far more complex -- and what if you DON'T want to  
follow into sub-groups.

> 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.

Actually -- you may be PARTIALLY on to something, but wouldn't it be  
better to define these relationships in action=attr?

The bonus there is that people can edit the page without changing the  
heirarchy.

This would imply NOT to use the Category/Tag group -- create a new  
basic group like Levels, define the parent/child relationships via  
action=attr so that only people with permissions to change page/group  
attributes can do it.

If Category was to be used, I'd suggest defining the group category  
via editing the Group.GroupAttributes pages and adding the category  
link there.  But I think that using action=attr makes a whole lot  
more sense -- as does defining a new group to define relationships.   
A tag is NOT a heirarchical relationship.

> 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...

If we don't (mis?) use the categories like this, then this isn't an  
issue.  It would be too easy to set up conflicts if we used  
Categories, and other recipes are already using them for simple  
tagging/indexing -- not book/part/chapter/subchapter types of  
relationships.

Crisses