[pmwiki-users] ZAP syntax ideas...

[Ben Stallings]

Dan wrote,
> 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.

So then the decode command could be restricted to particular page 
groups, which not everyone can edit?  If so, that sounds good.  I need 
to be able to use email addresses, but also to hide them from view.  If 
the decoding could be done automatically by the email command(s), and 
the email command(s) restricted, so much the better.

> (: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:)

I really like (:input session:), if you can make it fit the standard 
syntax of (:input session field value:).  Much more intuitive than (:zap 
field=value:).  Could get tricky with some of the commands that are 
submitted via (:zap:) tags, but maybe they could have their own 
(:input:) tags as well...

Intuitively, it seems like the other two should be (:input form 
method=link:), and (:input form method=auto:) because what you're doing 
is changing the method by which the form is submitted, and the form tag 
is where that information is traditionally specified.  Since you're 
talking about keeping the (:zapform:) markup, why not add a method 
parameter to it?  It could be tricky to program, but it would be worth 
it!  :-)

> 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)}

Yes, but that limits the information that can be passed.  I like 
(:zapform method=link:).  Otherwise, why not just use [[group.name]]? 
Or {$ScriptUrl}?n=group.name for the full address?

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

But nextpage only redirects if the form is processed successfully, 
right?  Redirect implies it redirects regardless, and forward... I'm not 
sure what that implies.  I say leave well enough alone on this one.

> 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

Seems like Pm's on top of this one with his soon-to-be-released ability 
to specify the editform to be used.  Or am I misunderstanding your 
objective here?

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

As the person who reported this conflict, let me first say it's a 
non-issue, since I can easily change DataPlates to use -cond instead of 
_cond for query conditions.  No problem.

But... to address a larger question you didn't ask... it is inconvenient 
that fields named both "email" and "Email" are treated specially by ZAP, 
making them unavailable for field names in other recipes.  It means that 
DataQuery users, for example, using ZAP to interface with an existing 
database whose fields already have names, may have to rename the email 
fields in their queries so as not to trigger unwanted ZAP actions. 
Fortunately DataQuery provides a way to do this without altering the 
database, but it's easy to forget to do it.  And since you asked, if you 
were to rename these reserved words to something less common, I'd be 
grateful.

For example -- just brainstorming here -- perhaps the email field could 
be something like SendEmail (to indicate it's a command... extensible to 
SendEmail_2, SendEmail_Dan, etc.) and the Email field could be 
Encode_Email (to indicate it is to be encoded).  Verbs like Send and 
Encode are much less likely to appear in field names by accident than 
are nouns like email.  I realize backward-compatibility is an issue, but 
since you're talking about freezing development, forward-compatibility 
is even more of an issue!  ;-)

Thanks again for being so open to feedback, Dan!  --Ben