[pmwiki-devel] Request to review code for Group Titles recipe

Tue May 20 22:25:53 CDT 2008

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 layer

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.

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
> <dominique.faure at gmail.com> wrote:
>   
>> On Tue, May 20, 2008 at 8:08 AM, Henrik Bechmann
>> <henrik.bechmann at sympatico.ca> 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.php
>>>>>>             
>>> Any 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;
>> }
>>
>>
>> --
>> Dominique
>>
>>     
>
> 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 [@@]).
>
>   

-- 

Henrik Bechmann
bechmann.ca
Webmaster, celos.ca webhosting services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-devel/attachments/20080520/3bf5fd02/attachment.html 