[pmwiki-users] ZAP syntax ideas...

[The Editor]

Though I've pretty much frozen ZAP on new features, my work on an
alternate wiki engine (experimental) has forced me to rethink how a
few things are done with ZAP in PmWiki.  It's also suggested some
other ideas unrelated to ZAP.  Thought I would post the ideas here for
input.

1). Currently ZAP has a create command and an edit command. The create
command creates new pages, the edit commands can do the same but also
insert sections (like Fox) and insert individual lines (like ADL).  I
was thinking I should perhaps delete the create command (as it is
duplicate functionality), and perhaps subdivide the edit command into
three

edit: pages
insert: for anchored section insertions
log: for individual line insertions

I would need to rework this section of the ZAP code, but in the
process it should (hopefully) make things a lot clearer. And also
simpler codewise--as the edit command has to be very smart to handle
all the possible options, flags, parameters, properly. And I could
make some things more automatic--ie easier for the form creator.

2). I'm also thinking of changing the datapage command to target.
Currently datapage is only used for saving data values (text vars),
and edit, create, etc. have to have their own mechanism for defining
which page is to be edited/created. In using a more generic name,
"target"  could be used for all of these functions and again simplify
the syntax they use (ie no editbody, etc).

3). Currently there is a code command in ZAP which encodes all listed
fields using an internal coding mechanism. It works great for things
like passwords and emails, and can be readily decoded (reasonably
safely) by an admin or an individual user. I'm thinking about changing
this to encode, and add a decode command. This would make it easier to
allow things like emailing password reminders, etc.

4). There is a very nice email_list command which allows you to send
emails to a CSV list of members (Bob,Dave,Mary,Kate). This is opposed
to an email_news command which allows you to send to a list of actual
email addresses.  I'm thinking of changing this to an email_group
command which could be combined with a nice group management system
based on pages like Group.Webmasters or Group.ChessClub. It would be
very easy to add/delete members in ZAP, set up ingroup conditionals,
group count markup expressions, and more. I'm not sure it can be
integrated into PmWiki's group authorization system, but that would be
great if it could.

5). ZAP has several custom markups for forms including:

(:zaplink:) Sets up a link that will submit a zap form
(:zapsubmit:) Sets up a form that will auto submit a zap from
immediately when the page loads.
(:zap field=value:) Stores a value as a session value which is
automatically added to the POST array when the form is submitted.

I'm toying with the idea of changing the markups to more generic type
markups like:

(:input link:)
(:input auto:)
(:input session:)

There's also a zapform and zapend markup. Already the zapend markup
can be replaced by (:input end:).  The zapform could perhaps be
changed to (:input form zap:) or some other flag to trigger the zap
engine, but I'm inclined to leave these two the way they are. I
conceptually like the idea of sandwiching a ZAP form in between these
tags.  But the rest perhaps should all be more standard looking input
types.

6). Now for a nonZAP suggestion...  I'm wondering if there can't be a
markup for nested tables using indents to determine embedded tables.
For example

(:table:)
(:cellnr:)
(:cell:)
  (:table:)
  (:cellnr:)
  (:cell:)
  (:cell:)
  (:tableend:)
(:cell:)
(:cellnr:)
(:cell:)
(:cell:)
(:tableend:)

7). It seems to me ZAP's link command (which creates a fully qualified
URL to a wiki page) could just as easily be replaced by an expression
markup like

{(link group.name)}

In my own mind at least, I'm becoming a bit more sensitive to what is
better as a forms command, a markup expression and a page variable.
And so wanting to get some of these things cleared up if I can

8). There was a suggestion to replace the savedata and erasedata
commands with simply save and erase.  (Fortunately this would not
break any existing forms).  These are shorter and more concise, but I
wonder if there is merit in keeping the data suffix to clarify we are
saving/erasing text var data, not page content or something else. In
this case I find the data suffix somewhat helpful.  The same goes for
the passdata command, which sends data as GET variables... Or perhaps
it should just be changed to get? Or passget... Yikes!

9). Speaking of GET vars, ZAP currently has a (:zapget:) directive
which retrieves all available GET variables and makes them into page
variables that can be used on a page.  It seems more reasonable to
replace it with a markup expression

{(get var)}

10). I'm wondering if there is any strong feeling about changing the
nextpage command to forward, or even redirect. (It controls where the
browser is forwarded to on form submission). I like nextpage as clear
and meaningful, but forward or redirect may be a bit more standard for
some.

11). Perhaps the coolest thing I've done on my experimental wiki is to
use ZAP forms for actions.  So for example:

index.php?n=Group.Name&action=edit

Will display the Action.Edit page with all the page variables from
Group.Name available in setting up the page (retrieving page content,
etc). Kind of like Site.AuthForm does. So to create a new action you
just create a new ZAP form, as simple or as complex as you like.

I'm wondering if this couldn't be done in PmWiki by doing something
like the following:

pmwiki.php?n=Group.Name?action=zap&zap=edit

The only thing is I'm not sure of is how to overwrite the displayed
page with Zap.Edit while maintaining the page variables for
Group.Name. It might be something simple. If so, it could really be
powerful...

12). A namespace conflict recently came up with ZAP involving it's
ability to use input fields like email_1, email_2, email_3 to trigger
instances of the email command multiple times.  Actually, any value
can follow the underscore.  I'm wondering if it should be limited to
numbers only, or leave it wide open to allow admins to use any kind of
flag to identify each instance.  For example email_thankyou,
email_tech, email_admin (this would only be useful if each email
message was different in content).


Anyway,

My goal is to have ZAP frozen in concrete by around the time PmWiki
comes out of beta, so I'm making a very thorough analysis of all
things ZAP.  Your input is VERY welcome...

Cheers,
Dan