[pmwiki-users] MarkupExpressionsExtensions

The Editor editor at fast.st
Sun Apr 15 12:48:28 CDT 2007


On 4/15/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> The Editor wrote:
> > Just released (renamed actually) a recipe entitled
> > MarkupExpressionsExtensions which adds a number of extensions to Pm's
> > recently released MarkupExpressions recipe.
> > ...
>
> Since several of these extensions have obvious relation to ZAP
> (even going as far as including "ZAP" in the configuration variable
> name or function name), could we possibly rename the recipe
> to the shorter ZAPExpressions?

If you wish, but it tends to get buried down at the bottom of the
list. I'd rather keep it here, and solicit input from others who would
want to help improve the code or add further extensions.  As some of
these extensions are quite useful, this seems like a good place for
them.  I'd even be open to Pm taking over maintenance of the recipe,
as he would no doubt make good improvements I could then import back
into ZAP...

As for the connection with ZAP, I only put the extensions here that
work apart from ZAP, and only used the config variables I use in ZAP
to make it easier for me to update the recipe. If someone else wanted
to help with maintaining it, these could be changed easily enough.

I find these VERY useful and just want to share them with the community.

> Some other comments:
>
> - {(attr title)} allows people to view the title of read-protected
>  pages.  Same with {(attr keywords)} and {(attr description)}.
>  Also, it's not clear why we need these versions of the markup when
>  we already have {$Title} and {$Description} (and could easily add
>  {$Keywords} if that's desirable).

Good point.  If you would like to add $Keywords (perhaps to core) I
would just change this to a password function for admins.  Very useful
for that.

>  In short, there really ought to be a clean distinction between
>  page variables and markup expressions -- to me,
>  title/description/keywords are clearly page variables (they're
>  values associated with specific pages) and not expressions.

You are right.

> - I think {(server ...)} really ought to use the actual $_SERVER
>  names instead of introducing its own.  Otherwise authors have
>  to learn a different set of names for things that already have names.

Perhaps, but an admin that knew enough php to know all the server vars
would probably just be doing page variables or setting up their own
local extensions. My position as usual is to help those who don't
really know php.  Here's a comparison of the terms I chose and the
actual definitions.  Perhaps others would like to weigh in on which
would be simpler or more clear to use:

return        HTTP_REFERER
browser     HTTP_USER_AGENT
secure       HTTPS
ip              REMOTE_ADDR
host          SERVER_NAME
software    SERVER_SOFTWARE
query        QUERY_STRING

Though Pm is quite good at choosing syntax, I think in general we tend
to need an advocate on this list for the non programmers who use
PmWiki.  Also I should note, things like software and browser are
useful places for the strpos function we discussed earlier...

> - The {(wiki ...)} expression is likely to be problematic
>  from a long-term design perspective, but that's just my opinion.

If you make the (:: (:pagelist :) ::) change you propose awhile back
and I can figure out how to make it work in ZAP, I'd be happy to drop
this.  I put it up deliberately thinking it might end up being a stop
gap measure.

> - In particular, {(wiki pagelist ...)} has the potential to cause
>  page saves to time out, as PmWiki will then try to compute a
>  pagelist when it goes to save the page.  Currently PmWiki
>  escapes any (:pagelist ...:) directives when saving a page,
>  to avoid this.

This is a very nice and useful feature.  With a lot of potential I
don't think we've really tapped into yet. Is it possible the pagelist
could be escaped in such a way it acts on the word "pagelist" so it
would escape it for either markup?

>  This also means that link= targets in pages will change,
>  because PmWiki will start to count the results of (:pagelist:)
>  commands as being valid targets of a page.  (And those will
>  become out of date because the result is computed only when the
>  page is saved, and not when its viewed.)

Do you have another suggestion? Thanks for pointing this out...  I
would really like this capability. In ZAP I also can embed ZAPforms...

> - The {(math ...)} markup is broken, because the $ZAPmath
>  variable is never set.  Also, lines like the following
>  produce fatal errors, because 'break' can only occur inside of
>  a looping or switch construct.
>
>    if ($p == '') break;
>    if (!preg_match($ZAPmath, $p)) break;

Fixed.  This was an unintentional holdover from before I separated the
ZAPmarkups recipe into independent extensions.

Cheers,
Dan



More information about the pmwiki-users mailing list