[pmwiki-users] Cluster Side Bars

[Kathryn Andersen]

On Mon, May 14, 2007 at 02:18:55PM -1000, Sivakatirswami wrote:
> Kathryn Andersen wrote:
> >On Sun, May 13, 2007 at 04:37:32PM -1000, Sivakatirswami wrote:
> Outstanding, great... that's very "neat"... Cluster has been a real
> boon... I reviewed the whole hierarchical group discussion today. I
> actually think this is better in many ways than some of the proposed
> alternatives and would have to agree with PM that other options don't
> really get us anything but complications. I like the clarity of what
> we have.

Thank you!

I'm currently working on a new version of Cluster which will optionally
enable name-based clustering as well as group-based clustering, which
will be really neat, IMHO.  Big rewrite though, and not quite compatible
with the existing one (some config and directives changed).  I also want
to make a site with a bunch of examples, so that will take time too.
 
> So Cluster may turn out to be The Final Solution (smile) for those
> of us who like simplicity.

Oh, I think PM could come up with something better if he wanted to delve
into the problem (but yeah, totally see why he doesn't want to at this
point).

> >What makes you think that the documentation says that you need to create
> >a $Group.SideBar page for each level in the cluster?  One *can* create
> >them, yes, but the whole point of Cluster is so that one can configure
> >things for a cluster of groups *without* having to do a separate
> >configuration for each group in the cluster.
> 
> It just goes back to an earlier " wish" I had
> when we started this whole discussion last year or early
> this year... that we have some nomenclature gaps such
> that  when docs refer to $Group, but if applied to
>  "whatever we want to call it top level, Kingdom, Matriarch Group"
> that the recipe will cascade to the whole Cluster.

Hmmm.
 
> I guess because you do not explicitely state something like
> "if you create a Side bar for  the Top Level Group
> (what are we calling this "Matriarch" of the cluster);
> it will be applied to all "Child" groups thru the Custer.
> we still think $Group is still one group however you slice it.
> as such "$Group.SideBar" does not automatically indicate
> that it will be applied as in effect: "$Cluster.SideBar"

Noted; will change the docs.

> [[aside: Having a "$Cluster" variable might be interesting,
> perhaps it is there already...]]

$g1 is the first "segment" of the group name, one could consider
it to be the top-level "cluster" variable.

> Musings: "Cluster" implies a group of equivalents, but in fact
> 
> Kingdom
> Kingdom-genus
> Kingdom-genus-species
> 
> *is* a kind or hierarchy, though everyone objected to defining it as such.
> but the cascade of effect of your recipe really is hierarchical in effect
> I mean g1, g2, g3... what is this if not a hierarchy? OK, I hear the
> rumblings
> in the background... yes, of course we know
> it doesn't work like we all think of it in a directory, sub-directory kind
> of way in which the top level "contains" it's children.

It's a pseudo-hierarchy.  It isn't a full hierarchy, because certain
things (such as page and group names) don't behave like a "full"
hierarchy would be expected to, so I don't want to be misleading.
The term "hierarchy" raises certain expectations which Cluster doesn't
meet.  Therefore, IMHO, it isn't the best term to use in this case.

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