[pmwiki-users] Cluster recipe

[The Editor]

On 2/15/07, Kathryn Andersen <kat_lists at katspace.homelinux.org> wrote:
> On Thu, Feb 15, 2007 at 09:50:38AM +1100, The Editor wrote:
> > On 2/14/07, Kathryn Andersen <kat_lists at katspace.homelinux.org> wrote:
> > > 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.
>
> My understanding is that a ResolvePageName function takes the $pagename
> (global variable) and turns it into a "standard" PmWiki page-name (in
> Group.Name format).
>
> $pagename = ResolvePageName($pagename);
>
> Therefore, if you have a $pagename which is Sub/Group/Name, then
> HgResolvePageName would then turn it into Sub-Group.Name
>
> So if you had
>
> include_once("$FarmD/cookbook/hg_urls.php");
> include_once("$FarmD/cookbook/cluster.php");
>
> then the $pagename would have already been processed by
> HgResolvePagename (inside hg_urls.php) and would already be in
> Sub-Group.Name format, which Cluster would understand.
>
> PM?  Is that correct?

Ah, I see what you mean.  Yes I think you are correct.

> > > 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.
>
> Ah.  You're using ROS patterns.  That explains it.
>
> I think a better method of going about it would be to use ROS combined
> with a page-variable.  You could call the recipe LinkPrefix, because it
> could be of general use whether or not one was using Cluster.
>
> It could be quite short, too.
>
> First, you make a LinkPrefix page-variable.
>
> In local/config.php (or in local/MyGroup.php or whatever)
>
> $FmtPV['$LinkPrefix'] = 'MyGroup-';
>
> Then, you make a ROS pattern
>
> $ROSPatterns ["/\[\[[^{]/"]   = "[[{$LinkPrefix}";
>
> Which would replace the unmodified link with a reference to the
> {$LinkPrefix} variable.
>
> To enable a '::' markup to *not* have a link-prefix, you could add
> another variable, and another ROSpattern:
>
> $FmtPV['$NoLinkPrefix'] = '';
>
> $ROSPatterns ["/\[\[::/"]   = "[[{$NoLinkPrefix}";
>
> Therefore links with :: will be saved with the {$NoLinkPrefix} variable,
> which resolves to nothing (thus, no link-prefix).
> The links which don't already have a page-variable at the start, will
> be saved with the {$LinkPrefix} variable, which will resolve to
> whatever one has set $LinkPrefix to.
>
> And the normal PmWiki processing will then interpret the {$PageVariable}
> markup; no extra processing involved, and Cluster doesn't have to
> interpret ':' markup.

As noted earlier it could be done separately.  Just less efficient.

> > 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...
>
> See above.
>
> > But then again, what would be the disadvantage of making cluster able
> > to handle either kind of url automatically?  Wouldn't that be easier?
>
> The disadvantage is that it makes Cluster harder to maintain and debug.
> I really don't want to have to deal with changing URLs.

Understood.  But Cluster wouldn't have to change urls.  It's just
about being smart enough to READ either kind of url.

> > > 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...
>
> There's a trade-off, yes.  But I think they do work better as
> independent recipes.  Easier to debug and maintain.
>
> > 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....
>
> See above.  I think they can both be done as independent recipes, and it
> certainly would be easier for me that way.

I suppose that's the way some programmers think.  Lot's of little
widgets you hobble together to make what you want. I prefer something
a bit more integrated, especially if it improves efficiency. Keeps my
work as a web admin simpler. So if you don't feel inclined to
accommodate more flexibility into Cluster maybe Hg should stick around
for awhile.  Some may appreciate the added functionality.  I know I
will be wanting it for my site--both clean urls and prefixing. So I
might as well keep it available to others.

Thanks for all the improvements you've brought in.  Some great ideas.
I'll make an effort to incorporate some of them into Hg when I get
back home from this round of travels.  Definitely the hyphen linking
and probably the group titles (though I'm not sure I will use them).
The sidebars?  Not convinced. :)

One good thing, if we must have two recipes, is that both Hg and
Cluster use the same syntax for linking and the same underlying
approach to hierarchical groups--so we won't be confusing people
between the two.  And it seems people should be able to swap either
recipe interchangeably with no loss of shared funtionality.  That's a
positive for PmWiki.

Cheers,
Dan