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

[The Editor]

Thanks Pm!  Here are a couple quick comments for the group.

On 9/11/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> I can't say much for certain, other than I suspect that
> {OtherGroup.{$Name}$:var} will probably do what you want/expect.

Fantastic!  I didn't expect this.

> > 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 understand.  Once again, my commendations for such fine software.
Whatever you've done to get this far, keep doing!

> > 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.
[-snip-]
> 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.

I understood this much.  Perhaps my question is why we don't switch
those markups to preserve backward compatibility.  That is, keep
{$var} referring to the currently browsed page and {.$var} referring
to the page from which it is written.  Advantages of this are:

1.  Full downward compatibility.
2.  The page variables (by me at least) are use almost exclusively in
headers, footers, etc, where I want the existing function. And if
preserved for those kinds of pages, this avoids having to make the
markup work differently in different kinds of pages.
3.  The "." seems to suggest root, which has a semantic connection to
the root page, not the secondary page (the page being browsed).
Easier to remember, perhaps.
4.  It puts the burden of knowing this extra syntax on those doing
more advanced stuff, with simpler syntax being used for more simple
stuff (like groupheaders/footers).

Just a thought.  It will not be onerous to have to change my site, but
would prefer to avoid it if possible.  And setting a flag to retain
current markup just delays the inevitable.  Can't wait for the new
markup--however it turns out!

Cheers,
Caveman

PS.  Good to be back in my cave...