<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Dominique, interesting material.<br>
<br>
Before getting into the general issues...<br>
<br>
Regarding the main case you present of wanting a special return result
for GroupTitle on the default page of the group itself, I have started
to move that kind of conditional to the wiki page level, thanks to the
maturation and flexibility of PmWiki's markup conditionals.<br>
<br>
For example I have a <a
href="http://parkcommons.ca/wiki/wiki.php?n=Help-Documentation.BrowserPageLayout">template
component</a> that I call "content header" (like group header, but site
wide), which contains the following code:<br>
<br>
================== start =====================<br>
<br>
(:if ! name {$DefaultName}:)<br>
%image-inline%Path:{$SkinSharedDirUrl}/page_ti.gif%% You are on the
'''[{*$Title}]''' page of folder '''[{*$GroupTitlespaced}]'''\\<br>
%image-inline%Path:{$SkinSharedDirUrl}/coverpage_ti.gif%% For the cover
page of this folder go to the
[[{*$Group}.{$DefaultPage}|'''[{*$GroupTitlespaced} cover page]''']]<br>
(:else:)<br>
%image-inline%Path:{$SkinSharedDirUrl}/coverpage_ti.gif%% You are on
the cover page of folder '''[{*$GroupTitlespaced}]'''<br>
(:ifend:)<br>
<br>
================== end ======================<br>
<br>
(this requires more work, in particular a "display path", or
"bread-crumb trail, but that's another story)<br>
<br>
In general, I view PmWiki installations as consisting of several
layers: <br>
<br>
- the core (pmwiki core installation, particularly the driver script
(pmwiki.php) and the files in the scripts/ subdirectory)<br>
- the configuration level (add-on php files and supporting files such
as skins), or "application" layer<br>
- the administrative layer (configuration options available through the
browser)<br>
- the user (author) layer<br>
- (I suppose) the reader layer<br>
<br>
I have come to view the core as primarily an engine, and the
application layer as being a combination of extensions and skins,
including support for specific administrative options, that implement
author services in a usable fashion. The application together with the
administrative options (such as the above wiki code) become a
"package", which is tailored to a particular purpose or audience. My
current purpose happens to be community organizations and their members
(quite a challenge, but that's yet another story). I currently have a
couple of dozen of these. Small, and supported by a single PmWiki farm
installation.<br>
<br>
In this view, the core is the source of general services that can be
used by applications. As such I view services in the core being,
ideally, fairly simple. <br>
<br>
>From this perspective, I would prefer the kind of over-ride options
that you propose to be included at a higher level in this stack.<br>
<br>
For an implementation example, see
<a class="moz-txt-link-freetext" href="http://cityrinks.ca/wiki/wiki.php?n=ListOfRinks.RinkDiaries">http://cityrinks.ca/wiki/wiki.php?n=ListOfRinks.RinkDiaries</a><br>
<br>
Note that the GroupName ("ListOfRinks" as seen in the URL) has been
renamed (with a PTV at
<a class="moz-txt-link-freetext" href="http://cityrinks.ca/wiki/wiki.php?n=Site.GroupTitles">http://cityrinks.ca/wiki/wiki.php?n=Site.GroupTitles</a>) to "City Rinks
Details", which appears in the menu at the left (through [[target|!+]])
and in the content header (using {$GroupTitlespaced}, as well as the
browser title bar).<br>
<br>
But the general point is that wiki markup conditionals can (and in my
view of things often should) handle exceptions such as the one that you
propose.<br>
<br>
Secondly, your proposed code reveals a facility with the core services
of PmWiki which is, quite frankly, still beyond me. In particular, your
skillful use of the markup engine, while intriguing, makes me a bit
uncomfortable, as it appears to require a specific context within which
the markup engine data structures are in the state required to perform
the functions that you call. Since I view the MakeGroupTitle function
as something that could be used as a service by other application
enhancements, this implies that MakeGroupTitle may be called in a
context that does not satisfy the requirements of your enhancement.<br>
<br>
Finally, in my context, believe me it will be all I can do to get
people to understand and accept the idea of the Site.GroupTitles
over-rides of the default file-level group names (itself a difficult
thing to explain to my audience), never mind getting them to understand
complex search strategies, defaults, and over-rides for Group Titles.
So in my context, I don't think your enhancement would be used.<br>
<br>
Nonetheless, the suggestion of an over-ride is obviously one that could
be used in other contexts (though I would quibble with the redundancy
of {$Group}.GroupAttributes$Title}). Getting back to the idea of
"packages" of components, including enhancements to support the
concepts of those packages, I think it is entirely appropriate to have
various versions of the same utility, so long as they are
cross-referenced and the differences documented. For example Hans has
the ShowHide utility, which is quite sophisticated and flexible, and no
doubt useful for many applications, while I have the simpler ToggleHide
utility, as it matches more closely the needs of my application.<br>
<br>
So I hope that you will feel free, if you wish, to (for example) update
the GroupTitle utility that you and Pm developed some time ago, perhaps
with a combination of the exploitation of PTV's that I propose, and
your enhancements.<br>
<br>
Thanks so much for your detailed and informative feedback.<br>
<br>
Best,<br>
<br>
- Henrik<br>
<br>
<br>
Dominique Faure wrote:
<blockquote
cite="mid:599dbcaf0805200515y38e8d53dydc6e69c0e39590c@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, May 20, 2008 at 2:00 PM, Dominique Faure
<a class="moz-txt-link-rfc2396E" href="mailto:dominique.faure@gmail.com"><dominique.faure@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, May 20, 2008 at 8:08 AM, Henrik Bechmann
<a class="moz-txt-link-rfc2396E" href="mailto:henrik.bechmann@sympatico.ca"><henrik.bechmann@sympatico.ca></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">All,
Peter Bowers made some helpful observations and suggestions, which
prompted me to make some changes resulting, I think, in safer, slightly
faster, and more general code for this. The updated Beta 2 is at...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The code is at <a class="moz-txt-link-freetext" href="http://www.pmwiki.org/pmwiki/uploads/Cookbook/grouptitles.php">http://www.pmwiki.org/pmwiki/uploads/Cookbook/grouptitles.php</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Any other comments are most welcome.
Best,
</pre>
</blockquote>
<pre wrap="">IMHO, one of the best feature of the original Pm's GroupTitle recipe
was to consider a search path when looking for titles, providing a
convenient way to 'override' the group title on specific pages:
For example, if the [[GroupName.{$DefaultName}|!+]] link is a simple
way to come back to the group home page, it isn't very useful on the
GroupName.{$DefaultName} page itself. The search feature should allow
to (re)define it there (to an empty string in this case).
The following code would be able to handle the path search, but I
haven't been able to find a "simple" way to allow fetching of empty
string definitions.
function MakeGroupTitle($pn, $group = '') {
global $GroupTitlesPathFmt, $pagename;
if (!$group) {
$page = MakePageName($pagename, $pn);
if (preg_match('/^(.+)[.\\/]([^.\\/]+)$/', $page, $match))
@list(/*$d*/, $group, $name) = $match;
if (!$group) return $pn;
}
SDV($GroupTitlesPathFmt, array(
'{{$FullName}$:GroupTitle}',
'{{$Group}.GroupAttributes$Title}',
'{{$SiteGroup}.GroupTitles$:{$Group}}',
));
global $RedoMarkupLine, $MarkupTable;
foreach($GroupTitlesPathFmt as $v) {
$rdm = $RedoMarkupLine;
while(true) {
$RedoMarkupLine = 0;
$v = preg_replace($MarkupTable['{$var}']['pat'],
$MarkupTable['{$var}']['rep'], $v);
if(!$RedoMarkupLine) break;
}
$RedoMarkupLine = $rdm;
if($v) return $v;
}
return $group;
}
--
Dominique
</pre>
</blockquote>
<pre wrap=""><!---->
BTW, replacing the last test:
if($v) return $v;
with:
if($v) return preg_replace('/\\[(==|@@)\\]/', '', $v);
you would be able to specify empty group titles using empty blocks
([==] or [@@]).
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
bechmann.ca
Webmaster, celos.ca webhosting services</pre>
</body>
</html>