[pmwiki-users] Can any of the form recipes do this?

Patrick R. Michaud pmichaud at pobox.com
Mon Apr 2 14:08:40 CDT 2007


On Mon, Apr 02, 2007 at 07:45:21PM +0100, Hans wrote:
> Monday, April 2, 2007, 7:30:31 PM, Patrick wrote:
> 
> > I'm not at all saying that Fox "absolutely must" change
> > its {var} syntax.. I'm just indicating that it's a design
> > choice I wouldn't have made myself (for the reasons
> > given in my previous message), and that I can't guarantee
> > that it won't pose a core conflict in the future.
> 
> I carried over this syntax from AddDeleteLine2. ZAP is using the same
> syntax as well. So there are three form processing scripts using it,
> plus the smiley recipe for {happy} etc smilies.

I didn't realize that ZAP was using it, also.  I knew about the
smilies recipe... but that's a little less worrisome to me because
the smilies recipe isn't usually the foundation of a larger application
(like Fox and ZAP are).

> I tried to save the smilies, and other curly markup, from Fox eating
> them, by using the following pattern when doing var replacements, for
> more precise matching of {var} and not more:
> 
> '/\{([^{*$[$].*?)\}/e'

Actually, this pattern will still match {{var}} -- it just does so on the
second brace.  At a quick glance, it also appears to match {+inserted+}, 
{-deleted-}, {Page$Var}, {=$Var}, {<$Var}, {>$Var}, etc.

If Fox is sticking with single curlies, your best bet would be to
match alphanumerics only, with:

   /(?<!\\{)\\{(\\w+)\\}/e

You need the initial (?<!\\{) to prevent the pattern from matching {{var}}.

> and use a "save the smilie" function to allow any {name} through, which
> are not filed names in the fox form, to minimise conflicts.

This helps, but for the non-smiley forms (e.g., {+inserted+}) it would
be a lot better to not match the pattern in the first place.

> Is this reasonable? sufficient? Or shall we abandon the {var} syntax,
> and what would be better?

I propose (and plan to use) {$$var} to mean "substitute a value from another
source into this template".

> Also: markup of kind {var} is only present in template pages Fox uses
> to construct a new page, or page section, and inside the the from
> markup and the input markup.

This also helps, but in some sense it could still conflict if those templates
are to ever contain any other {...} markups.

> It is probably a good time to revise all this, as PmWiki 2.2.0 is still
> in beta, and the form processing recipes relying on it and are also
> still beta.

My current plans for future markup syntax in this area:

    {$$var}      - template substitution
    {$?var}      - value from query string ($_GET)
    {(foo bar)}  - functional markup (e.g., substr, date, etc.)

But at this point I make no guarantees on the exact syntax or meanings of
any of the above.  :-)

Pm



More information about the pmwiki-users mailing list