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

[Martin Fick]

  Weeee... the unification is here. :)

  My comments inline.  

  Anything I didn't comment on sounded great!

  (Well, so did the stuff I commented on)


On Thu, Dec 15, 2005 at 11:35:13AM -0600, Patrick R. Michaud wrote:
> So, now that we have some uniform mechanism for displaying
> the attributes of the current page, how about other pages?
> I think I like the ideas that led to the Cookbook.PageVariables
> recipe -- namely that a page variable can be prefixed by a pagename
> to obtain the value for that page:
> 
>     {OtherPage$PageUrl}  -- url of OtherPage in the same group
>     {Group.Page$Title}   -- title of Group.Page
> 
> Here's the critical insight:  if we adopt the convention of using
> {$...} for page variables even in PHP code, then this means that
> we can use the above page-qualified forms even in PHP strings and
> recipes, and that nearly all page variable substitutions take 
> place in FmtPageName instead of special-purpose markup rules.  
> FmtPageName can also take care of reading and caching any
> page attributes as they are needed, instead of it being spread
> throughout the codebase as it is now (on the expectation that
> FmtPageName *might* use them).

  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.  

  Overall this might make it easier to migrate recipes to
the new format.  It would be readily obvious when a recipe
has not been updated and you would not have to worry about
breaking  compatability.  Maybe eventually when you want to
eliminate FmtPageName(), you could simply make a recipe out
of it so that users could still install it if they needed it
for older deprecated recipes.




> But let's go a bit further.  We sometimes need a "page cursor",
> for example when walking through a list of pages, or when
> processing an include file.  The PageListTemplates recipe
> handles this with {$Curr}, {$Prev}, and {$Next} markup, but I 
> think I'd like to embed a cursor directly into page variables,
> using =, <, and > to represent current, previous, and next.
> With that in mind, we get the following:
> 
>     {=$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!




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




> But there's more:  the (:include:) markup and 'wiki:' template
> directives can set the cursor to the name of the included page. 
> Then {=$FullName} is the always full name of the included page,
> unlike {$FullName} which is the full name of the currently browsed
> page.  Thus a page can use {=$FullName} to always refer to itself
> even if it's being included from another page.  Same goes for
> {=$Title}, {=$LastModified}, etc.


  Way cool, a great feature, but I would be carefull with
overloading the = operator here.  As you describe it in this
last paragraph, it tends to give the feeling of permanence
or absolutness to the =, i.e. it is the TRUE pagename, no
matter where it is viewed from.  This is not really the
concept of a cursor!  Then on the other hand, in the 
pagelisttemplates case it is a cursor and something that
varies greatly.  Having the same markup for these two ideas
seems bound to cause confusion amongst authors.

  You said:  
  
    "Thus a page can use {=$FullName} to always refer to itself
     even if it's being included from another page."
   
  except if that page is used as a pagelisttemplate that
would not be the case!

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





> Wow, that's cool.

   Yes, yes, yes, very cool

   -Martin