[pmwiki-users] New {$$ } and {( )} markups [Was: Can any of the form recipes do this?]

[The Editor]

On 4/3/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> I think you're missing the point.  Here's an example conflict:
>
> 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?

Ok, I see what your saying.  So {$$ } is not a markup either--just
syntax you are planning to use for templates. If that's the case it
wouldn't interfere at all with my field replacements system. But I
might have trouble putting {$$ } into a ZAP created template page via
a ZAP field , because ZAP would think it's a field replacement. It's
kind of a chicken or the egg problem. Extreme possibilities, perhaps,
but worth considering.

At the very least I am willing to go along with the {$$ } markup for
templates if that's what you are going to do.  And then perhaps  keep
{ } in the form input for field replacements.  These are two different
functions.  That solves both problems... How does that sound?

> > 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 .

Good.  As noted above, I didn't quite catch that, as we were talking
about markup conflicts.

> > 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.

ZAP would not mess up any such markup, though such a markup might mess
with a ZAP form.  But the problem then would be that that is bad
markup? Not really with ZAP.  Right?

> > >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:

Fine, I'd suggest releasing it as a recipe first so I can have some
time to fix ZAP over to work with it.  Though it would be nice if it
was made flexible enough to put it right into core, perhaps even in
this beta series.

> 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)}

Though it's not all documented, there are some nice features in ZAP's
{(time)} function already.  It would be more clear to have it work
with field=value parameters, but I'd like to not have to lose
functionality.

Cheers,
Dan