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

Patrick R. Michaud pmichaud at pobox.com
Fri Sep 8 10:40:22 CDT 2006


On Fri, Sep 08, 2006 at 04:18:49PM +0100, Américo Albuquerque wrote:
> On Fri, 8 Sep 2006 08:15:46 -0500, Patrick R. Michaud wrote:
> > We're looking at a more natural way of setting variables than
> > the recipes' (:set var=...:) markups. 
> >
> Ok but you'll still need some way to say that you want them to be set as
> variables or every text that is written in the same way will also be set
> as variable

Not at all.  It only becomes a variable if it's *used* as one.
For example, having markup with

    Title: this is a title
    Name: this is a name

doesn't do *anything* special until someone writes {$:Title} or 
{$:Name}.  It's only when the page variable is encountered that 
the page is scanned looking for "Title:" or "Name:".

> > We're also looking at a better way of extracting variables, by using
> > {$:var} instead of {$var}, to make it clear it's coming from the page
> > markup text. 
> What would then be the difference between text variables and page
> variables? Just their origin?

Well, there's actually a bit more difference than that.  Text
variables would come from a page's content, yes -- a text variable
is just a convenient way to extract a value out of the page's markup.  

Page variables are really more like "page functions" -- i.e., 
while we tend to think of {$Name} and {$Title} as being static 
values, in reality they are more dynamic than that.  For example,
{$Title} returns the value of a page's (:title:) attribute, and
if that doesn't exist it returns the page's name.  {$PageUrl}
computes and returns the url of the current page (which can be
different depending on the value of $EnablePathInfo, among
other things).  

This is why something like {AnotherPage$PageUrl} can work, because
$PageUrl is a function that returns the url for AnotherPage.

> Currently all page variables are set in $FmtPV array. To avoid
> overriding them you would also need another variable holder...

No, the additional text variables can also go into $FmtPV, as
$FmtPV['$:Name'], $FmtPV['$:Title'], etc.  In the current version
of the recipe that I have they're dynamically added to $FmtPV
when they're encountered in the markup, although this may change.


> Does this mean we can currently override default page variables by
> setting $FmtPV['Name'] = "'Some other text that is not a page name'"?

Yes, it's entirely possible to override the defaults -- in this case
it would be $FmtPV['$Name'], however.   Of course, if the default
is overridden with something non-sensical then lots of things might
break, but there's nothing fundamentally wrong with changing the
defaults.  (That's why they're "defaults". :-)

> > > The problem using either recipe is the same, you can't set the variables
> > > inside a (:if:) and use it as a (:if:) clause at the same time without
> > > changing the core and even there you can't expect it to work like it
> > > would in a programming language
> >
> > Yes, we're not proposing to resolve this particular issue ... at
> > least not yet. It's still the case that page variables would be
> > defined for an entire page, regardless of any (:if:) constructs.
> >
> In http://www.pmwiki.org/wiki/Cookbook/Functions says that |PRR can be
> used to apply all markups again to the current line. Is there a similar
> function but that would apply to the entire text? I mean, from the
> inline phase restart it back to the fulltext phase?

Not really, because by the time we've reached the inline phase
the text has been broken up into an array of separate lines
that isn't easily joined back together for processing -- at least,
not without introducing a lot of other issues.

If we really need that sort of capability we could see about
adding it, but at present there's not really a good way to do it.

Pm




More information about the pmwiki-users mailing list