[pmwiki-devel] Cluster & skin integration

The Editor editor at fast.st
Sun Mar 18 09:52:26 CDT 2007


On 3/18/07, Hans <design5 at softflow.co.uk> wrote:
> Sunday, March 18, 2007, 12:03:06 PM, The wrote:
>
> It would be nice if Hg and Cluster would use the same function and
> function name. Then a skin can have the PVs for cluster subpages
> defined just once without worrying which clustering recipe is used.
>
> Hg and Cluster are alternative scripts, only one would be used, so
> they can use the same function names.
> How about ClusteringSubpageName($group, $name) for this function which
> generates the group ancestor pagename?
>
> I am trying to achieve a better integration, which will make it
> unnecessary to do extensive skin hacks. If it can support both
> clustering recipes even better. I am not out to wish to set
> preferences for one or the other.

Fair enough.  As Hg was first however, and Kathryn was unwilling to
accommodate any attempt to combine the recipes (and I don't like the
term Cluster, conceptually), I settled on a more neutral function
name...

HierarchicalPagenames($group, "SideBar")

I hope Kathryn will agree to the convention.  I'm also open to other
suggestions that don't involve the word Cluster.


> > However I did not want the breadcrumbs to look like the directory
> > structure--I want it to look more intuitive to what the viewer is
> > thinking.  So I used a Site.Breadcrumb page with a bunch of
> > conditioals to really rework the breadcrumb in various ways to get the
> > effect I need.  But with a hierarchical $BreadCrumb variable like this
> > new upgrade allows, it takes all the fun out of it.  It's now a piece
> > of cake!
>
> I think a group ancestor linktrail PV, i.e. breadcrumbs, can be very useful
> on a page, perhaps as part of the title section.

See my forthcoming post on new support for breadcrumbs.  Hg handles it
differently than Cluster, but in a way that is much more powerful.  I
hope this won't cause a conflict in your skin development.  If it does
let me know how I can work with you.

 > I still have an issue in the way you use the term hierarchical in
> connection to this link trail, and in connection to the group name
> structure employed in Hg and Cluster. You are still calling Hg a
> hierarchical groups recipe, even though you try later to explain it is
> quasi-hierarchical. It is about sharing and inheriting subpages, group
> attributes and group css files from a group whose name acts like an
> "ancestor" and is part of the current group name, defined with
> separator symbols. And only sharing this when it is missing in the
> current group. This to my mind is not hierarchical in any sense, not
> even a quasi sense. But it is difficult to describe, as I just found
> out typing this.

Yes, I understand what you are saying and appreciate it (I think).
And while it is true in no way produces hierarchical pages, the
"groups" are hierarchical in the sense everything is inheritable
according to an easily constructed hierarchy. (Perhaps programmers
only count them hierarchical if they have a hierarchical file
structure or something).  Anyway, in my thinking, the average user
wants hierarchical groups for certain effects.  Hg/Cluster gives it to
them.

Also, I did change the name to Hg from Hierarchical Groups (the
initial release) and I've helped to set up the Hierarchical Groups
page to explain what Hg/Cluster is and is not. Kathryn also helped on
that page I believe.

Cheers,
Dan



More information about the pmwiki-devel mailing list