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

[Patrick R. Michaud]

On Tue, Apr 03, 2007 at 03:38:00PM -0400, The Editor wrote:
> On 4/3/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >At any rate, I was fully intending {(...)} to be a standard
> >markup for doing computations at the time a page is rendered,
> >not as a template substitution markup.  Especially so that someday
> >we can possibly do things like
> 
> By someday, you mean as soon as it is available, correct?  ZAP markup
> already works in pagelist templates.  Very important.

The "someday" part was referring to the

    (:template first {(substr {=$Group} 0 1)}:)

part of what I wrote, which might not immediately work when
{(...)} is available (because the template directive only understands
page variables at the moment).  Within other parts of the
template it would work just fine.

> Also, I hope the processing order won't change too much.  It should be
> after page and text vars, and before conditionals.  Very important
> also.

Yes, that's where it will go.


> I'd still like something similar to what is available now.  An SDV
> ZAPphplist, etc that makes it easy to make any php command available
> to the markup simply by putting it into the list (or an array). 

This also makes it very easy to introduce unexpected security holes.
But for those who want it, it wouldn't be hard for ZAP to provide a
"ZAPphplist()" function that takes a list of php functions and
does whatever magic is needed to make those available via the
(extensible) {(...)} markup.

> ... but I get an
> uncomfortable feeling much of the capabilities I've put into the
> ZAPmarkups recipe is going to get thrashed in the process.

This is one of the hazards of being on the bleeding edge.  :-)

> Like Math really should be default.  Source, captcha, attrs, logging
> vars, etc.  

I don't have any plans to make any of these default,
because I fear it bloats the core a fair bit.  Defining a
common syntax to handle such things is worth having in the
core, but that doesn't mean the core should also define every
possible extension.  That's what recipes are for.

(By way of example: PmWiki currently defines the (: ... :)
syntax as being the common syntax for directives, but it doesn't
attempt to put every possible directive in the core.)

> Waiting uneasily to see how this shakes out.  I'm not too excited
> about having to get someone to enable 5-6 recipes to get a complex zap
> form going
> 
> ZAP to set up the engine
> ZAPextend to create the forum
> ZAPmail to email it to member lists
> Pm's recipe to set up the {( )}
> ZAPmarkupextend to add my custom functions...
> ZAPconditionals ?

I notice the only one in this list that isn't "ZAP" is the
{(...)} one, and there's nothing that prevents ZAP from
defining a {(...)} rule if one doesn't already exist.
As long as the end results gets processed pretty much as
people expect according to the common standard, there's
not a real "conflict" here.

Pm