[pmwiki-users] Cluster recipe

The Editor editor at fast.st
Wed Feb 14 16:50:38 CST 2007


On 2/14/07, Kathryn Andersen <kat_lists at katspace.homelinux.org> wrote:
> > > 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.
>
> Wouldn't it work if you just made sure that Hg-Urls was included before
> Cluster?  Because the HgResolvePageName function would then have already
> altered $pagename, yes?

No, because what the HgUrls function does is translate a link like
Sub-Group.Name into Sub/Group/Name in the address bar (or when you
mouseover).  Cluster has to be able to interpret that when it is
clicked.  Which is the work of HgResolePageName. So if cluster were
smart enough to read either format then it would be easy enough to do
the cleanurls thing.

If not I may just forget about it, because it doesn't really matter
that much to me.  I was trying to accommodate others who wanted it.
But it would be nice if we could make it available as an option.

> > > > Another advantage to Hg is that it has a built in powerful group
> > > > prefixing capability that can be used to great effect.  Basically you
>
--snip--
>
> I thought the group-prefixing stuff was done with the :: markup?
> How can it distinguish between when you want a prefix and when you
> don't?

Here's the idea behind it.  If the ROS pattern is set, it actually
adds a : to the beginning of the link when the changes are saved.
When there is one colon the prefix is added.  When there are two
colons the prefix (and colons) are ignored.  So to have absolute links
you just prefix with 2 colons.  The ROS (and potentially ROE to hide
the extra colons when editing) patterns are all external to the
recipe, in the local config files, but Cluster would have to be smart
enough to add the prefix if a link begins with one colon and not add
it when there are too.

So again, it's just giving Cluster the hooks to be able to do more
when desired. Things like prefixing and cleanurling could otherwise be
left to other recipes, or better yet, just add the little config lines
to the cluster page somewhere as an optional way to use cluster.

> > > 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...
>
> That's because you don't understand how page-variables work.
> It isn't any more complex than finding the appropriate GroupHeader; it
> just has to be in a separate function, with the $group passed in, so
> that it will work as a page-variable for any page, not just the current
> page.  You may well ask "Why would anyone want it for anything but the
> current page?" Well, I don't know, but if I'm going to have something
> that behaves like a page-variable, I'd like to do it properly.

I see.  Suppose there could be a use for this somewhere...

> > 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?
>
> As I said above, I *think* having a "ClusterCleanUrlsResolvePageName"
> function should be able to work independently of what Cluster does, so
> long as you make sure that the Urls recipe is included before the
> cluster recipe, so that its ResolvePageName function gets run first.

Not sure that will work as resolving the page name is so critical to
both how cluster works and the cleanurls.  Or are you saying if
$pagename is defined in two places only the first definition would be
used?  That is, if I defined pagename with a different function
elsewhere in the config file, the one in cluster would be ignored...

But then again, what would be the disadvantage of making cluster able
to handle either kind of url automatically?  Wouldn't that be easier?

> As for Prefixing, since I'm not entirely certain how it works, I'm not
> sure whether they would clash.  It might be that they would clash, since
> they are looking (I assume) at the link markup "[[" -- I'm not sure
> which one should go first.

Yes, I suppose prefixing could stand alone just fine.  Might even have
some advantages.  But it seems less efficient to have to have every
link go through 3 markup functions.  Prefixing, Rel/Abs Linking, and
then PmWiki's.  Combining the prefixing in Clusters Rel/Abs linking
markup function seems better...

Anyway, again, let me know if you would be willing to consider
accommodating the cleanurls in clusters resolve page name function.
Or hg's prefixing into Clusters markup.  That's the biggest obstacle
for me just ditching Hg completely.  The other option would probably
be me continuing to maintain Hg and just duplicate the changes you've
made that are worth adding back in.  (Still not convinced about the
sidebars :).  Sigh....

Cheers,
Dan



More information about the pmwiki-users mailing list