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

The Editor editor at fast.st
Tue Apr 3 07:58:42 CDT 2007


On 4/2/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Mon, Apr 02, 2007 at 08:49:26PM +0100, Hans wrote:
> > Monday, April 2, 2007, 8:08:40 PM, Patrick wrote:
> >
> > > 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.  :-)
> >
> > So now I consider changing for Fox:
> >
> > {var} to {$$var}
> > {date: string}  to {(date: string)}
> >
> > I am also using {[deletelink]} and some variations which Fox expands
> > into a fully working special purpose link for deleting a specific
> > page section. Are there possible conflicts to be seen? Any better
> > markup for this?
>
> I think {[...]} is pretty safe.
>
> Pm

Sorry--we had a storm part of the day yesterday and my satellite
connection was down for awhile and missed much of this discussion.
Here's a few reactions from the ZAP side of things:

First, I'm not too excited about changing the ZAP markup for field
replacements and templates from { } to {$$ }, as Hans seems so apt to
do. As for Pm's two basic arguments for making the change (possible
conflict with similar markups & probably use of {$$ } in core):

1) I'm not convinced there's much chance of conflict.  The way ZAP
handles them (like Fox, I believe), is that they are ignored if that
field value does not exist, allowing them to be processed by other
markup as needed.  So there's never a conflict with {+inserted+},
{-deleted-}, {Page$Var}, {=$Var}, {<$Var}, {>$Var}, etc.--and as
pointed out, the pattern could be improved for better efficiency if
needed.  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. In fact, the { } syntax does
not even involve a markup.  Just a pattern replacement handled
internally by ZAP. So as long as PmWiki or some other markup
definition doesn't mess these up when the page renders (and Pm
indicated he doesn't want these used as markup) there should never be
a problem.

2) I'm not sure ZAP/ADL/FOX should use the same syntax as core--as
that IS likely to produce conflict.  Yes it might allow for greater
consistency in syntax, but what if I wanted to create a pmwiki
template via some ZAP form, or some other page text involving this
notation, I could easily have a conflict between what ZAP is doing and
what PmWiki is doing.  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, meaning, I would have to have a syntax for ZAP field
replacements that did not trigger PmWiki's use of the same syntax.
Granted, what Pm has in mind is still nebulous, but I think it could
be a big mistake (Hans) to switch over prematurely.

On the con side to Pm's suggestion:

1)  I really hate the thought of breaking so many existing forms,
documentation, snippets, etc., that would be involved with this
change.

2) I much prefer the simpler syntax. { } is both more readible and
intuitive than {$$ }.

3) Biggest reason:  Hate the extra key strokes...

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.


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 note Hans version involves a colon while Pm's does not.  I could
perhaps add a : to differentiate it between ZAP and PmWiki.  But then
depending on how Fox handles this syntax, there might be a conflict
between it and those using ZAPmarkup with it (which works independent
of ZAP). So we then have conflicts all around...  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  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...  Being forced to upgrade their forms syntax, and yet not
knowing whether they'll have to change it again tomorrow.

Cheers,
Dan



More information about the pmwiki-users mailing list