[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:
> On Tue, Apr 03, 2007 at 08:58:42AM -0400, The Editor wrote:
> > 1) I'm not convinced there's much chance of conflict.
> > [...]
> > Perhaps more importantly, as these are *ONLY* used in ZAP
> > contexts (on form submission values) they in no way interfere with any
> > other markup used elsewhere on a page.
>
> ...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.  The { } both in ZAP and FOX are not
markups but just a syntax handled post form submission.  Even in a
template, ZAP uses only the source code--so even a markup like { }
would not effect the template process in ZAP.

> > 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.  So if I
put

(:input text Field1 '{$$Field2}':)

and pmwiki makes some kind of substitution when the page renders, when
the form is submitted, ZAP won't be able to do its field replacements
(inserting contents of Field2 into Field1 after submission. This may
not affect Fox so badly because while it does field insertions in a
template (based on the source code), it doesn't to my knowledge do
field replacements.

> > At the very least, until more information is
> > forthcoming about how these will work in PmWiki, I'm more inclined to
> > wait and see whether ZAP might want to be able to handle the markups
> > directly
>
> No problem.  As I said in my followup message [2], I'm not at all
> asserting that any existing recipes "absolutely must" change their
> syntaxes -- only that I think it's a risky way to go, and that as
> PmWiki looks at convergence with other markup languages we may find
> that {...} has to be available for something else.  (Consider LaTeX.)

I don't know anything about LaTeX, and I'm willing to go along with
the consensus, but I'm just a bit hesitant to make a major change
without some clearly identifiable problem, when I see more probable
risks in adopting something very likely to become a core markup ie {$$
}.

I understand there is a risk to ZAP that some other markup will come
along that would mess up this field replacement when the page loads.

(:input text Field1 '{Field2}':)

but perhaps there's some other way around it, like a {{ }} markup
which returns Keep({ }) when LaTeX is enabled or whatever...  But then
again--that recipe is using the kind of bad markup you are
recommending against, not ZAP/Fox.

Could you give an example of a likely potential problem?

> > 1)  I really hate the thought of breaking so many existing forms,
> > documentation, snippets, etc., that would be involved with this
> > change.
>
> Welcome to my world.  Sometimes the way to avoid breaking things
> in the future is to avoid steps that might paint us into a corner.
> (Using {...} as a generalized markup has the potential to do that.)

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.

> > On the introduction of a new functional markup {( )}, I am a bit
> > perturbed, as I've just completed a major rewrite of the ZAPmarkup
> > module using this notation (based on Pm's encouragement) and reworked
> > all the snippets and documentation at ZAPsite to use the new notation,
> > only to discover now (days later) it about to be taken over by a new
> > (identical) core syntax.  It's a good syntax, and it was Pm's idea,
> > but I wish he hadn't encouraged me to use it!  :)
>
> I didn't say that it's imminent, only that we might want to eventually
> fold something like this into a core syntax.  But this is also a
> case where we'd probably introduce {(...)} in a manner that doesn't
> break ZAP (or at least not in a big way), so don't panic just yet.

Ok, I realize that. You've always been quite good about this kind of
stuff. I probably over reacted on this point.

> It's also very possible that {(...)} would end up being a recipe
> as opposed to a core markup.

If you want to take the ZAP markups script and rewrite it in a way
that is more extensible (or I could do it), I could move the functions
you don't like out and then let you maintain the main recipe. Or even
put it in core. It would be easy enough to use the same extensibility
model I used in ZAP for the markups. Very slick. That would solve
another problem I've been chewing on about how to make it possible to
pick and choose between the various markups available (like ZAPextend
does), so users could only add certain ones as desired, and perferably
directly into their config file.  Would you like me to take a stab at
that?

> > I note Hans version involves a colon while Pm's does not.
>
> My version might end up using a colon -- I'm still thinking
> about it.  But at this point I'm thinking it likely won't.

I'm currently not using a colon.  It looks cleaner.

> > [...] Depending on how Pm
> > sets up the core function (I'm assuming it will be extensible), I
> > could rewrite the ZAPmarkup module to take advantage of any features
> > he doesn't bring into core.
>
> Yes, any markup I bring in would definitely be extensible.  The
> (:directive:) markup has been quite extensible, I don't see any
> reason why {(...)} cannot also be extensible.

Is there something I'm missing in terms of directives?  All my zap
directives are separate markups.  Perhaps there's some extension
function I should be using?

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.

> > But in the mean time, I'd really like some
> > input on where to go with this--as I just deprecated the old {#
> > markup} to the dogpile--so my users are now caught in a bit of a
> > bind...
>
> Well, my original warning was against the single curly brace as
> a closer.  I did suggest {(...)} as a potential replacement, but
> I wasn't necessarily expecting ZAP to make a wholesale switch
> so quickly, or without a bit more discussion about its internal
> syntax.

Remember, ZAP's original name was FAST...

> For example, ZAP's version of {(...)} appears to use the vertical
> brace as argument separators, which seems very different to the
> approach that most other PmWiki markups use, which is to use
> whitespace to delimit arguments and key=value pairs.  PmWiki
> even provides an excellent ParseArgs() function to do all of the
> argument parsing, so I'm a bit surprised to see a syntax based
> on vertical braces as separators.  It's definitely not as clear
> to read -- I would have never guessed that "HomePage" in the
> following means "exclude HomePage from the count".
>
>    {(count Snippets|HomePage)}
>
> Something like the following would be much clearer:
>
>    {(count group=Snippets name=-HomePage)}
>
> Similarly, instead of
>
>    {(time Next Thursday|+9h|%m %d)}
>
> it might be nice to have
>
>    {(time "Next Thursday" fmt="%m %d")}
>
> so that people aren't guessing as to what the arguments mean.  As
> an example, I have absolutely no clue what the meaning of "+9h" is
> in the earlier version.

Yeah, you may be right.  I like the shorter notation, and it's more
consistent with what I need to do in ZAPfields but probably not so
easy for someone not working with it all the time.  I'd be willing to
change it, or let you rewrite it for core if you plan to...

As for ZAP fields something like

(:zap Command="param1='value' param2=value param3='value'":)

might work too, but I think at least here params within a param is a
bit problematic.  So

(:zap Command="param1|param2|param3":)

strikes me as more clear.  Just the same in light of pagelists and
other directives, the {( )} should follow a similar notation.

> So, to get back to your original request ("input on where to go on
> this"), I'd say that it's okay to continue with {(...)} for now.
> For consistency with other markups I'd recommend moving to a more
> ParseArgs-style syntax over the existing arg1|arg2|arg3 syntax,
> but that's your option.

Any other feedback from anyone else?  I'll go along.

> 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.  Then ZAP and Fox can extend that as needed,
> and we'll have much less opportunity for conflict with the {(...)}
> markup in the future.

I think it would be a good idea.  If you like me to take a stab at it,
I'd be happy to tackle the extensibility issue, and re-release the
ZAPmarkup script as a more generic recipe.  Those features you don't
want in the main release I can find someway to make available
separately--though that means just one more module people will need to
enable, or one more config code you'd need.

Let me know which you'd prefer.

Cheers,
Dan