[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