[pmwiki-users] Cluster recipe

The Editor editor at fast.st
Wed Feb 14 04:59:26 CST 2007


On 2/14/07, Kathryn Andersen <kat_lists at katspace.homelinux.org> wrote:
> On Wed, Feb 14, 2007 at 11:36:30AM +1100, The Editor wrote:
> > On 2/14/07, Kathryn Andersen <kat_lists at katspace.homelinux.org> wrote:
> > > On Tue, Feb 13, 2007 at 09:04:28AM -1000, Sivakatirswami wrote:
> > > > Kathryn Andersen wrote:
> > > > >I've uploaded a new version of the group-cluster recipe:
> > > > >http://www.pmwiki.org/wiki/Cookbook/Cluster
> > > > >
> > In contrasting the two recipes, heres a few thoughts to consider...
> >
> > First, it should be noted that Hg accepts either cleanurl like links
> > or regular PmWiki type links.  So it's not a choice between either
> > or...  And the function that converts links into cleanurls is easily
> > turned on or off.  When off, there is no difference in this regard
> > between the two recipes.
>
> No.  As it stands, Hg *always* calls hgResolvePageName whether
> $hgcleanurls are on or not.
> It also breaks normal CleanUrls, if one wants to have something like
> Kingdom-Animal-Canine/Dog

The fact it calls that function only means Hg will accept either type
of url in the address bar.  The thing that sets the cleanurl links is
the hgUrl function--and that only kicks in when cleanurls is set.
I'll check into the conflict with regular CleanUrls, but there's not
really any need for it with Hg.  And in fact, Hg seems to work even
where regular CleanUrls don't, like my home system.

> > If there is a preference Hg could be changed to leave it off by
> > default. Actually, probably a good idea, as it would help new users
> > understand what Hg is doing. To me having both options available seems
> > a better approach as some definitely like the cleaner look.  And with
> > it optional, it might save us from having to maintain two virtually
> > identical recipes...
>
> Would it be possible to just extract out the "urls" part of the Hg
> recipe, and use it alongside Cluster?

Actually, maybe.  It would be easy enough to strip out the hgUrl
function and the line that sets the PageUrl.  But Cluster would have
to be able to read it in the resolvepagename function. Again in Hg
that function can read either format and automatically interpret it
properly.

> > Another advantage to Hg is that it has a built in powerful group
> > prefixing capability that can be used to great effect.  Basically you
> > can define a subgroup and have all links automatically prefixed such
> > that they are placed within that group.  For example, I plan to use
> > this to allow member to create their own individual wiki spaces with
> > normal group.name linking. It too can be turned on or off, and can be
> > overwritten when turned on to provide normal linking.  So these are
> > two big plusses to hg.
>
> I don't really see that "group prefixing" is so wonderful; you can get
> the same kind of thing with a page variable.

Maybe I didn't explain well what prefixing is.  (Or I don't grasp how
you could use a page variable...)  In Hg, if I set the prefix, then I
can be in some subgroup and [[Group.Name]] will automatically be
interpreted as [[Subgroup-Group.Name]]. This means for example new
users can each be given a full wiki like space within a hierarchy.
Very powerful.  How can you do that with just a page variable?

> > On the other hand, looking at the Cluster code I noticed Kathryn added
> > some rather complex sidebar stuff. Though there's no documentation on
> > it, I'm wondering if you have changed how Cluster handles sidebars--or
> > if it works as Hg?
>
> What I've done is simpler from the user point of view; as with Hg, in
> order to use the sidebar stuff, you need to edit your skin template.
>
> A normal skin template would have something like this:
>
> <!--wiki:{$Group}.SideBar {$SiteGroup}.SideBar-->
>
> What Cluster does is give you an additional page-variable, so you can go
>
> <!--wiki:{$SideBar} {$Group}.SideBar {$SiteGroup}.SideBar-->
>
> instead.
>
> The $SideBar page-variable will be set to the appropriate side-bar for
> the current group, doing the search in the same kind of way that
> GroupHeader or GroupFooter etc are searched for.

Isn't that redundant?  I mean in Hg, it automatically checks for all
the subgroup sidebars and if none is found it goes to the
sitegroup.sidebar.  Guess I don't get the point of all the extra code
you put in...

> Also, Hg is incorrect in that it is looking for "Sidebar" instead of
> "SideBar".

Oops.  Thanks for pointing this out.

> > Also, Cluster added a good Group Title idea which
> > I will probably add to Hg when I get back from Melbourne.  :)
>
> I got sick of these really long group names. 8-)
>
> > Kathryn, were there any other functional changes you made in Cluster?
> > I notice you made quite a few code changes, but theres no
> > documentation on the cluster recipe page of any differences in how it
> > works.
>
> The searching is basically the same algorithm.  I completely rewrote the
> page-variables stuff because, alas, you still seem to have misunderstood
> how page-variables work, and the current version of Hg has broken them
> again.  Also I made the variable names more verbose because I wanted to
> be able to understand what it was doing when I come back to it in six
> months time and have completely forgotten what I was thinking when I
> wrote it...

Are you sure about the page variables.  Didn't think I had changed
that part of the code.  If so, I'll look into it again and fix it.

> I also changed the SDV variable names to comply with the conventions
> used by other PmWiki recipes (that is, put them into CamelCase).
>
> Additionally, I created the "-" link markup, which is a shortcut for
> "child-group of the current group"; I found that very useful when I had
> groups like the following:
>
> Fiction-Stories-Crossover
> Fiction-Stories-Crossover-Highlander
>
> With the original Hg markup, to get a shortcut for the second group,
> when linking from Fiction-Stories-Crossover, I had to go
> [[^-Crossover-Highlander/]] but with the "-" markup, all I needed was to
> go [[-Highlander/]] which is much easier.

Very nice.

> > Also have you used the new group home page feature in the
> > latest beta release of PmWiki yet?  Or do you even have group
> > homepages capabilities in Cluster?
>
> What do you mean "new" group home page feature?  Yes, the GroupTitle
> uses "$Group.$DefaultName" in its list of pages to search for the
> group-title, just as the GroupTitle recipe does; apart from that,
> since Cluster isn't changing the URLs, it doesn't need to worry about
> group home pages.

Don't know if Pm documented it yet, but he added a way to set the
default page name for groups to something besides the group name.
Like Main or HomePage.  This is very important for getting something
closer to a true hierarchical groups functionality, as you can set up
scripts and config values to do certain things if a page is a group
homepage.

I had a system in Hg to do this that won't be needed any longer.  Just
wondered if you incorporated the new core code yet.  Now that I think
about it, it shouldn't work independently of Hg/Cluster, so it's kind
of an irrelevant question...


Kathryn, it looks like you are doing some nice stuff with Hg and I
really don't have time to maintain it.  If you would consider making
the Cluster resolvepagename function able to read either format (both
cleanurls and -. format) then I'd likely just drop Hg and add two sub
recipes, one called Cluster-CleanUrls and another called
Cluster-Prefixing, and make those available as simple optional addons.
 What do you think of that idea?

Cheers,
Dan

PS.  Did you just see the fireworks a few minutes ago?  Very nice!



More information about the pmwiki-users mailing list