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

[V.Krishn]

On Monday 11 September 2006 20:21, Patrick R. Michaud wrote:
> 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.

{(function args)Group.PageName$[?:# ...](index)var}
I was wondering what could this (index) be of use off.
Could this use eg (.) to denote - 'create unambiguous expansion or expand the 
variables before getting the values back'.
Other uses could be (>) or (<)

V.Krishn

>
> 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.)
>
> Pm
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users