[pmwiki-users] Cluster recipe

[Kathryn Andersen]

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?
 
> > 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.

> 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.
 
> > 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.

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