[pmwiki-users] New {$$ } and {( )} markups [Was: Can any of the form recipes do this?]
Patrick R. Michaud
pmichaud at pobox.com
Tue Apr 3 10:05:51 CDT 2007
On Tue, Apr 03, 2007 at 10:39:51AM -0400, The Editor wrote:
> On 4/3/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >...but can you guarantee that other markups on a page that end up
> >with "{...}" in them won't interfere with ZAP? What if I define a
> >{{foo}} markup, and {foo} means something in ZAP?
>
> No conflict. {{foo}} would do it's thing during the page rendering,
> and unless it ended up with a { } in a field value, it would have no
> impact on a ZAP form submission.
I think you're missing the point. Here's an example conflict:
PmWiki 1.0 used {{...}} as a "free link" markup. For 2.0 I switched this
to always use double brackets for links, and part of the reason for
doing this was to explicitly free up the {{...}} markup for others to
potentially use.
So, suppose I want to create a ZAP template containing (literally)
"{{Field1}}" as markup for the output of the template. I'm not wanting
anything to be replaced here -- I want the string "{{Field1}}" to
appear after all of the substitutions have taken place. How do I
do this if ZAP is going to change any occurences of "{Field1}"
with the value from Field1 from my form?
> >> 2) I'm not sure ZAP/ADL/FOX should use the same syntax as core--as
> >> that IS likely to produce conflict.
> >> [...and then much later...]
> >> Also, I thought it was nice Fox, ADL, and ZAP all used the same
> >> template syntax basically, meanting they were interchangeable. If
> >> Hans change Fox, it will just make things more confusing, not less.
> >
> >I have trouble reconciling these statements -- if a lot of recipes
> >are using identical syntax, there's no overwhelming reason to keep
> >the syntax out of the core.
>
> Currently, a person can use essentially the same template syntax { }
> with forms in ADL, ZAP and FOX. Which is nice. If Hans changes to
> {$$ } that will no longer be true. Not a big deal of course, but nice.
> That's all I meant.
>
> However, if these three use {$$ } for its template/field replacement
> syntax and PmWiki gives it a markup meaning, we may well have
> conflicts between PmWiki and these forms processing recipes.
No, I explicitly said that PmWiki would be using {$$...} for
substitutions _in templates_, not as markup to be rendered.
See http://www.pmichaud.com/pipermail/pmwiki-users/2007-April/041232.html .
> Yes, I appreciate this. But then again, we do still want the simplest
> syntax for the most common uses. And remember { } is not a markup.
Perhaps not, but you keep missing my point that there may be many markups
that use {...} as part of the markup.
> I'm thinking for the {( )} module it should allow you to define
> certain functions that are called if they exist. So you could easily
> add functions without having to touch the markup engine.
Sure, I was thinking along similar lines.
> >Or, if we really think it's worthwhile to standardize {(...)},
> >I propose that we go ahead and identify some standard functions
> >that everyone seems to want (time, date, substr, toupper, tolower,
> >etc.) and I'll write a base recipe for it that can stand apart
> >from either ZAP or Fox.
>
> I think it would be a good idea.
I'll go ahead and do this, but given my current workload it'll
take me a day or two to get a prototype together. Essentially
the format will be:
{(name args)}
where "name" will be a lookup key into an array of functions, and
"args" will be passed to the function as a parameter. It'll be
up to the function to parse the arguments (preferably calling
ParseArgs(), but the function can choose a different argument format
if desired).
The standard functions I'm thinking of making available will include:
{(date)} # arguments to be determined
{(time)} # arguments to be determined
{(strftime "fmt")}
{(substr "string" start length)}
Arguments to the above can be specified either positionally
{(substr "Hello" 4 1)}
or by keyword
{(substr "Hello" start=4 length=1)}
Pm
More information about the pmwiki-users
mailing list