[pmwiki-users] Imminent new ZAP release...

The Editor editor at fast.st
Wed Apr 11 09:40:14 CDT 2007


Just about to release the upgraded version of ZAP.  Here's a last
chance for comments, questions, feedback on the proposed changes
before I make the release...

1) There will be two ZAP modules:  ZAP and ZAPtoolbox.  The first is
the core engine, the second is all the other existing commands,
modules, markups and conditionals organized into commented clusters of
related stuff.

2) For greatest efficiency and security, an admin can just enable ZAP
where desired, and then cut and paste functions from the toolbox into
local config files.  No need to enable ZAPtoolbox anywhere.

Note:  I revised my own current {( )} markup rule to make it possible
to break up the existing ZAP markups into individual functions.

3) Those who wish to may simply enable ZAP and ZAPtoolbox, and
everything is available to them. This should be reasonably safe on
sections of your site not open to public editing.

If you do enable ZAPtoolbox, you can immediately lock all extension
functions by simply creating a Site.ZAPConfig page--which allows you
to specifiy the pages and/or groups each command is enabled for.  This
makes it easy to turn extensions on and off without having to edit
your config file. You cannot lock conditionals or markups, though
doing so for markups is a possibility.

4) Though I have steered away from the more complex suggestions for
including/not including various parts of the toolbox, I may create an
$enableZAPcart variable to turn that one section on or off, as it
consists almost entirely of markups and SDV variables that really
don't need to be defined everywhere.  Not sure how much processing
time will it save to not define those definitions, but figure it's
worth a try.


Other changes:

1) Login and registration by default will now save all information on
one page (Profiles.AuthId) and ZAP's internal encoding/decoding
mechanism will be applied to passwords and emails.  Options for
separate Login pages, and fully encrypted passwords still exist.

2) The emaillist and emailnews commands have been changed to
email_list and email_news for various internal code reasons.

3) Some markups will now require a trigger word to activate: ie php
commands require php, directives require wiki and server vars require
server.  The other markups remain unchanged in syntax, though some
will probably be rewritten to accommodate a friendlier syntax using
parseargs if/when Pm releases his version of the markup.

4) Templates will use the {$$var} markup, though field replacements in
the form submission will continue to use { }. Also recently changed is
the order of processing so field replacements are made more
intuitively, at the time each command is processed.

5) I'll be separating the validate command into a validate and
required function.  The first checks strictly for patterns, the
required function only tests that a field is not blank. Currently
validate requres it to pass both checks.

6) I'm still toying with the idea of creating a ZAP super markup which
retrieves complete ZAP forms from a Site.ZAPForms template page, but
may wait as I haven't settled on the right markup yet.  Any ideas?

Cheers,
Dan



More information about the pmwiki-users mailing list