Thanks Dominique, interesting material. Before getting into the general issues...
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.
For example I have a template component <http://parkcommons.ca/wiki/wiki.php?n=Help-Documentation.BrowserPageLayout> that I call "content header" (like group header, but site wide), which contains the following code:
================== start =====================
(:if ! name {$DefaultName}:)
%image-inline%Path:{$SkinSharedDirUrl}/page_ti.gif%% You are on the
'''[{*$Title}]''' page of folder '''[{*$GroupTitlespaced}]'''\\
%image-inline%Path:{$SkinSharedDirUrl}/coverpage_ti.gif%% For the cover
page of this folder go to the
[[{*$Group}.{$DefaultPage}|'''[{*$GroupTitlespaced} cover page]''']]
(:else:)%image-inline%Path:{$SkinSharedDirUrl}/coverpage_ti.gif%% You are on the cover page of folder '''[{*$GroupTitlespaced}]'''
(:ifend:) ================== end ======================(this requires more work, in particular a "display path", or "bread-crumb trail, but that's another story)
In general, I view PmWiki installations as consisting of several layers:- the core (pmwiki core installation, particularly the driver script (pmwiki.php) and the files in the scripts/ subdirectory) - the configuration level (add-on php files and supporting files such as skins), or "application" layer - the administrative layer (configuration options available through the browser)
- the user (author) layer - (I suppose) the reader layerI 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.
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.
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.
For an implementation example, see http://cityrinks.ca/wiki/wiki.php?n=ListOfRinks.RinkDiaries
Note that the GroupName ("ListOfRinks" as seen in the URL) has been renamed (with a PTV at http://cityrinks.ca/wiki/wiki.php?n=Site.GroupTitles) 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).
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.
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.
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.
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.
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.
Thanks so much for your detailed and informative feedback. Best, - Henrik Dominique Faure wrote:
On Tue, May 20, 2008 at 2:00 PM, Dominique Faure <[EMAIL PROTECTED]> wrote:On Tue, May 20, 2008 at 8:08 AM, Henrik Bechmann <[EMAIL PROTECTED]> wrote: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...The code is at http://www.pmwiki.org/pmwiki/uploads/Cookbook/grouptitles.phpAny other comments are most welcome. Best,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; } -- DominiqueBTW, 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 [@@]).
-- Henrik Bechmann bechmann.ca Webmaster, celos.ca webhosting services
_______________________________________________ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
