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

The Editor editor at fast.st
Tue Apr 3 14:38:00 CDT 2007


On 4/3/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:

> Well, I think it would be confusing to (template) authors if some
> {(...)} markups are replaced when a post is made, while others are
> replaced when the page is displayed.  They really ought to be
> different markups.

Agreed.  kind of confusing.  Perhaps Fox should stick with it's old
syntax for this kind of stuff.  Or use input fields.  It works nice in
ZAP that way.

> I know this starts to look terribly ugly, but one could do
>
>   {$$(date ...)}

Agreed also.  Ugly.  Semantically sensible I suppose but ugly.
Wouldn't it be easier to just pass it via the ZAP form?

> Or, we could always do funny things like having a common
> prefix for functions that are intended to be done as part
> of the template expansion, as in
>
>    {(t:date ...)}
>    {(t:substr ...)}
>    {(t:foo ...)}
>
> but somehow that doesn't seem a whole lot different from {$$(...)}

Worse, I suppose.  Though you do have lots of letters to choose from.  Or even

{*(time)} or {(*time)}

Somehow comparable to the difference between {$var} and {*$var}.  But
again, I think it could just as easily be passed via the form.
Doesn't Fox already do that anyway?

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

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.

> But we could support both, with something like
>
>    {(phpdate ...)}
>
>    {(date phpfmt="Y-m-d")}

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). I
should know better given Pm's awesome track record, 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.

Like Math really should be default.  Source, captcha, attrs, logging
vars, etc.  Really most everything in the latest ZAPmarkup's script is
good.

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 ?

Maybe I'll combine ZAPmail into ZAPextend, and combine my markup
extensions you don't put in core with ZAP conditionals.  That would
give me three recipes total.  If your recipe was then moved into core,
I'd actually come out ahead or the current recipe count...

Cheers,
Dan



More information about the pmwiki-users mailing list