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

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

I see.  Great idea!

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

Flattery, flattery.  :)

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

But some of the ones you chose seem a bit problematic.  Time for one,
plus strftime?  Date?

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

Fair enough.  But is this recipe you write, when it's moved into core,
going to be on by default or only turned on as needed?  I'd suggest
turning it on with little or no functionality by default and then let
the recipes hash out the extensions by individual functions or
whatever.

Thanks for taking an interest in this.

Cheers,
Dan