[pmwiki-users] ZAP syntax ideas...

[The Editor]

Thanks for all the input.  Here's a brief summary of the direction I'm
leaning toward at present, plus a couple new ideas. In general, esp
with Dr. Fred's urging, I resisted all changes that would break forms
(where there was not a compelling reason).

If there are any further objection/comments, let me know as I have not
yet implemented any of this.

1.  create/edit -> edit/insert/log
I'll keep create for awhile, but deprecate it (add a msg to that
effect), and separate the edit command into edit (page) and insert
(section). This keeps ZAP more in harmony with the terms PmWiki is
heading toward. Duplicate functionality perhaps, but more flexible
when within ZAP... Edit is a VERY new feature so it shouldn't break
too many forms, and then, only when using it for insertions.

2. datapage -> target
I'll keep datapage for save/erasedata, though in ZAPwiki I will just
use target--and rework the syntax of edit/insert to better use of it.
It wouldn't make sense to use datapage with edit/insert--and may not
want both terms there.

3. code -> encode/decode
Decided against having a decode mechanism in a form as it allows
access to password information to anyone who can edit a form. Came up
with an alternate solution for providing password reminders to
members--which is the specific need I had in mind. Still I probably
will switch existing syntax from code/code to encode/decode as it
seems clearer. ZAP's coding mechanism is also very new.

4. email_list -> email_group
Will offer both with a warning that email_list will be deprecated
soon. Semantically it offers wide open possibilities for a group
management system in PmWiki. I'm hoping it can be integrated within
PmWiki's authentication system--but even if not, there's still a lot
of potential functionality.

5. zaplink, zapsubmit, zap -> link, submit, session
Besides breaking to many forms, it's good to make clear ZAP is
separate from core input markup.  I will use the simpler markups in
ZAPwiki as it will be core there.

7. link -> {(link page)}
Might as well keep this in.  It's pretty basic, and only one line.
True, workarounds do exist, but they look a bit clunky.

8. passdata,savedata,erasedata -> pass, save, erase
Probably will not do. The change would not break most forms, unless
there is a field like save* which would now become a command and not a
data field.  It also links them (the last 2 at least) with the
datapage command.  In ZAPwiki I will use the shorter syntax as it will
shave off four key strokes, and there will be no datapage command. In
fact I'll probably use data=field,-field for save and erase, as per
Jm's great idea.

9. (:zapget:) {$var} -> {(get var)}
Came up with a better idea still. Realized GET variables could be set
automatically as page variables without requiring zapget. It would
break no forms and make future forms easier. (:zapget:) could either
return '' or "zapget deprecaed" depending on how vital it was to
encourage admins to correct their code. Probably the blank is better.

10. nextpage -> redirect or forward
Will keep nextpage. As others pointed out, it may even be more clear
than either of the others.  Part of my goal for ZAP is to use
non-technical terms where possible.

11. action=zap&form=comment
This is only adding new functionality and I will do if Pm or someone
can explain how to overwrite the page that is displayed
programmatically--such as is done with the Site.AuthForm. It may not
be feasible, or necessary--as Pm's is already adding similar
functionality, that might just work fine with ZAP. It's already
working in ZAPwiki.

12. email_anything -> email_##
Will probably leave as is. There was only one reported problem, and
there Ben has a nice workaround available in his recipe. So until
there's a need, let's stick with this.

Jm also suggested some rather wild (powerful) possibilities in his
email.  Specifically, being able to assign multiple zap inputs in one
markup. A great idea--but conceptually I think it's easier in
developing ZAPforms for the admin to see each command as a programming
line.  It wouldn't be hard, or necessarily break form, but I think
I'll hold off on it for now.

In conclusion:

*There will be a slight reworking of the edit command that WILL break
forms using it to do foxlike insertions--but no other broken forms.
*Several commands will continue to work but be deprecated with warning
messages given to help in the upgrade process:  create, code,
email_list. Also, (:zapget:) will no longer be required.
*Deprecated commands will likely be dropped from the code when ZAP
comes out of beta just so the final code is cleaner.
*Once ZAP 1.0 is finished, any future changes (other than bug fixes)
will be put in ZAP 2.0beta, which will be offered parallel with ZAP
1.0stable. I should add, however, at this point I have no plans for a
ZAP 2.0.

Cheers,
Dan