[pmwiki-users] MarkupExpressionsExtensions

[The Editor]

After carefully reading the various posts on this thread, I'd like to
address a couple issues and propose a couple changes to the
MarkupExpressionsExtensions recipe.

1) Some of the content probably should be changed from
MarkupExpressions to Page Variables:  Specifically, establish a
$Keywords variable (to round out the $Title and $Description
variables.  (This is useful in ZAP at least as it can dynamically edit
this value if it has a way to prepopulate the input field).

2) I probably should do the same thing for variables like $PasswdEdit,
etc.  It would help if we had a clearer definition of what kinds of
functions are most appropriate for MarkupExpressions.  I'm thinking
things that process input and dynamically produce output based on that
should be MarkupExpressions.  More static values are better as page
variables.  Accurate enough?

3) In light of the above, $_SERVER variables should also be page
variables (as Hans noted).  I also agree with him (against a large
concensus), they should be more common names.  Here are the names I
propose:

$ReturnLink        HTTP_REFERER
$Browser            HTTP_USER_AGENT
$IPAddress         REMOTE_ADDR
$DomainName    SERVER_NAME

So the entire Server Extension I'll drop, and the above I'll add to
one of the documentation pages for those who may want to use them. Is
this a good enough compromise? That way admin's can rename them
whatever they want. In ZAP they'll stay easy to use names.

As for getting meaningful Browser information, I'll leave it to
someone else to come up with a better way to parse the USER_AGENT, but
will add a strpos Extension to the recipe as a partial solution.

4) The thread on doing Captcha suggests the best thing for this is
also a page variable. One advantage to the system I had was that you
can make the captcha number any number of digits, but a default 4
digit captcha number should be adequate for most cases.  Besides, Pm
has said he'll be developing his own captcha system I believe, so no
sense putting in extra code we don't need.

5) As far as Han's concern about using eval in the math function, I'm
pretty sure the function's pattern matching check on the input value
will eliminate any possible risk. It is a very nice, concise, and
functional bit of code--and it's been asked for by several people over
the last few months. Of course, if someone comes up with a better
solution, I'd be happy to see it changed.

6) I'll fix the functions that require a '' after the return. Also, if
there's too much prejudice against the name ZAP, I'll change the
various config variables and function names to something else. This
recipe should not be connected with ZAP, because ZAP already has all
these functions built in and more. It is only for non-ZAP users. Maybe
something like:  $mkexpext['math'], etc.  ???

On another note, I am enjoying toying with the idea of renaming ZAP
and ZAP Toolbox to Acme and AcmeToolbox.  Just a couple find and
replaces.  Hmmm... Guess that would make me the Wiley Coyote who keeps
coming up with these grand schemes that just keep backfiring!  : )  It
does seem to accurately reflect what a number of people think about
ZAP...

Cheers,
Dan