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

Américo Albuquerque aalbuquerque at lanowar.sytes.net
Fri Sep 8 12:52:23 CDT 2006


On Fri, 8 Sep 2006 10:40:22 -0500, Patrick R. Michaud wrote:
 > 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:".
 >
Ah, ok. How would it work when founding several values? Last value 
stands? Or will it create an array?
For example if you have

Section: header1
[some text about header1]

Section: header2
[some text about header 2]

How would it work when using {$:Section}? It would be handy if we could 
do something like {$:Section[1]} and {$:Section[2]}

 > > > 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.
So we can't use something like {AnotherPage$:Name} to get the text 
variable of another page?
If we can do that then the two behave in a similar way

 >
 > > 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.
 >
Ok, I understand now how it works. Basically the variable name it's its 
index in the $FmtPV array

 >
 > > 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". :-)
 >
Changing this defaults just change the page display, right? It might 
change the result of (:if:) markup but doesn't change the workflow of 
pmwiki?

(...)
 >
 > 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.
 >
Ok, it would help in case we need redo all markup to all the text but I 
guess that's not a priority and probably there already are better ways 
of achieving a similar effect







More information about the pmwiki-users mailing list