[pmwiki-users] About {$:var} text-variables

Patrick R. Michaud pmichaud at pobox.com
Mon Sep 11 09:51:02 CDT 2006

On Fri, Sep 08, 2006 at 04:57:53PM -0700, The Editor wrote:
> Being able to override the page this var is set from is also great,
> i.e.  {Group.Name$:var}.  The problem though as it seems to me is
> there will be many times the Group and Name variable will be dependent
> on a page variable themselves.  

I can't say much for certain, other than I suspect that
{OtherGroup.{$Name}$:var} will probably do what you want/expect.

> As far as adding capabilities to allow php functions, cross farm
> reading, data clips, etc, it seems the goal should be simply to allow
> hooks for recipe writers and leave those kind of applications for the
> cookbook.  [...]
> My hope in saying this, of course, is that the essential functionality
> could be released sooner if we lower our objectives for core just a
> bit.

Partially.  I still have to take into account how the advanced
functionality can be achieved, even if it's not implemented in the
core.  Indeed, this is partially why the core is so flexible, because
for many features I didn't ask "will something work now", but rather
"if I later want to do XYZ also, how will I do it?"

> I'd also appreciate it if someone could explain why a {.$:var} syntax
> is necessary.  

The problem is that page variables without a pagename qualifier
always refer to the currently browsed page, not the page that contains
the page variable.  For example, if I have a page called Group.ABC that
has the markup:

    Field1: I am page ABC, my name is {$Name}.

If I view Group.ABC, I will see "Field1: I am page ABC, my name is ABC.".
But, if another page (say, Group.XYZ) has the following markup:

    The value of Field1 from ABC is: {Group.ABC$:Field1}

then when we view XYZ we will see

    The value of Field1 from ABC is: I am page ABC, my name is XYZ.

In other words, {Group.ABC$:Field1} is replaced with
"I am page ABC, my name is {$Name}", and then {$Name} gets replaced
with the name of the current page; that is, "XYZ".

My proposal is that page variables such as {$Name} are always
evaluated with respect to the page in which the page variable is
written, as opposed to the one in which it is displayed.  This
would change the above such that {$Name} in the Group.ABC
page would always return a value of "ABC".

The purpose of the proposed {.$var} markup is to have a way to
say "I really do want a variable of the currently browsed page".
So, with this modification in place, if Group.ABC contained

    Field2: I am ABC, my name is {$Name} and I'm displayed from {.$Name}

then viewing Group.ABC would display:

    Field2: I am ABC, my name is ABC and I'm displayed from ABC.

Then, if Group.XYZ has

    The value of Field2 from ABC is: {Group.ABC$:Field2}

then viewing Group.XYZ would reveal

    The value of Field2 from ABC is: I am ABC, my name is ABC and I'm
    displayed from XYZ.

In other words, {$var} always refers to the page in which it is
written, and {.$var} always refers to the page in which it is displayed.
Most of the time these are in fact the same.  But when we start talking
about including content of one page into another, it's important that
we match authors' intuition as to what will happen, and most of the
time authors expect that when including ABC from XYZ, they'll get the
same thing they would've seen if they were viewing ABC directly.

(I know this is certainly the case for the (:include:) markup and
relative page links, where people expect the links in an included
page to point to the same place they would point if viewing the
including page directly.)


More information about the pmwiki-users mailing list