[pmwiki-users] Unifying variables, attributes, properties, part 2 (attributes)

Patrick R. Michaud pmichaud at pobox.com
Thu Dec 15 15:56:16 CST 2005


On Thu, Dec 15, 2005 at 01:33:39PM -0500, Martin Fick wrote:
> 
>   Maybe a new function is merited for this instead of
> FmtPageName(), something like PageVariable(). :)  This would
> allow you to keep the old "$Group" formatting in FmtPageName
> without having to upgrade it to handle "{$Group}" or even
> any of the new caching techniques that you might change. 
> Just consider it deprecated.  With this, your new
> PageVariable() function can do any new special caching magic
> and authaurizations checks.  The new function would also NOT
> need to support the old "$Group" format.  

It would still have to support "$Group", at least for a while.
Assuming that PmWiki's core code all switches over to using the
new function (as it would need to in order to take advantage of
the new page variable capabilities), then any existing local 
customization variable settings that use the old format would 
break.

But I'm still likely to slowly migrate things away from FmtPageName 
to a better-named and implemented function.  FmtPageName has become
crufty over the years (it was one of the first functions written
for PmWiki 0.1 in September 2001) and I've wanted to "fix" it for
a very long time but didn't have a good redesign framework until today.

> >     {=$Name}      - name of the page at the cursor position
> >     {<$Group}     - group of the previous page
> >     {>$PageUrl}   - url of the next page
> 
>   Yes, very nice, even better than our previous notational
> ideas.
> 
>   Maybe this could even be extended to represent the prev
> and next page in a trail!

That's a good idea, then the trail markup could be designed to
convert

    <<|SomePage|>>

to

    << {<$Title} | SomePage | {>$Title} >>

so that the previous and next links display titles instead of
pagenames.  :-)  The current implementation of the trail markup
would be

> > If there is no current, previous, or next page, the page 
> > variable returns an empty string.  
> 
>   I think that would take care of the PageListTemplates hack
> I used for blank pages, except for maybe if someone writes:
> 
> 	[[{>$Name}]]
> 
> and it the next page is blank.  This would lead to [[]]
> which is ugly (NOT blank) when rendered.

We can make it be blank -- that would certainly seem to be
the logical outcome.  Then [[]] also becomes another possible
notation for a null string, like [==] and '''''' do now.

> > But there's more:  the (:include:) markup and 'wiki:' template
> > directives can set the cursor to the name of the included page. 
> 
>   Way cool, a great feature, but I would be carefull with
> overloading the = operator here.  [...]

I agree, perhaps overloading = isn't the right approach.  But
we at least have a strategy whereby we could eventually handle
this long-standing request.

>   Some new suggestions for a permanence operator might be
> {!$Name}, or alternatively {$$Name} or {.$Name} might be
> good to mean the current "cursored" page.

I like '=' for the current cursored page, as it resonates well
with the common semantic meanings for '<' and '>':

     <     less than      before      previous
     =     equals         current     this
     >     greater than   after       next

Pm




More information about the pmwiki-users mailing list