[pmwiki-users] ZAPForms: docs + future

The Editor editor at fast.st
Mon Aug 13 15:10:59 CDT 2007


Just want to say thanks to all for taking up the ZAP project. And I
will very gladly continue to help anyway I can. It will be great to
see ZAP advance!

I should note however that it may be more difficult than you think to
progress--as the real problems, at this point, are limitations within
PmWiki. You may be able to overcome them--but ZAP has already pushed
PmWiki beyond it's intended boundaries, and Pm is not willing to
extend those boundaries. To do so would require fundamental changes,
that PmWiki simply cannot afford to make.

To illustrate what I'm talking about, someone committed to maintaining
ZAP really should take a serious look at ZAPwiki--as it has developed
so far in the last two months it is hardly recognizable in comparison
with PmWiki's brand of ZAP. (www.zapwiki.org). Once you grasp
conceptually what ZAPwiki does, you will be able to come up with a
real roadmap for ZAP 2.0.

If I were still using PmWiki, I would DEFINITELY try and built ZAP 2.0
off ZAPwiki rather than PmWiki/ZAP. Some of the things in particular I
would see as absolutely critical are:

* action pages -- building custom site & local actions right in the
wiki, with an action bar including not just view & edit, but create,
rename, copy, tags, delete/undelete, email, joingroup, title,
backup/restore, data, import/export, whatever...
* real member & group mgmt -- with easy (centralized), full access
controls for everything. Self registration, login/logout, profiles,
reset password, email verification, the whole works.
* invisible data storage (even in source) and fine tuned data access
authorizations so you have complete control over who can see every bit
of data stored on your site.
* fix pagelists to allow dynamically generated forms with real boolean
search capabilities -- including fully indexed tags, links, data, etc.
Cut out the div's and stuff that mess up the output.
* rework forms markups to simplify code, generate full session
control, solve order of processing problems, and automate locking
mechanism for multiple forms on a page.

And while you are at it (all indirectly related to ZAP):
* true hierarchical pages -- applied systemically throughout the site,
functions, and form commands.
* in wiki skins -- secure, live editing of html/js/css and test
results instantly. Fully flexible page zones system.
* improved markup table with intuitive line spacing, etc. Get full
control of your forms layout and output.

Most of these are either not possible without core changes, or require
major plugins that reproduce significant sections of PmWiki code and
bypass it's limitations. But then you are talking a gigantic
application. And you best hope it all fits together right.

This is one reason I raised the question of whether it's really best
to continue development of ZAP. Pm is going as far as PmWiki is able
in terms of forms processing -- within the bounds of PmWiki's
philosophy. It may end up being wiser to stay within that philosophy
(ie, limit yourself to those things you can creatively do with Pm's
basic forms capabilities and scratch the rest), or switch to a
different philosophical foundation that will naturally enable the
kinds of things you want. But that's just my conclusion after many
long, and enlightening conversations with Pm.

I should add, security, is not really the issue. Yes, Pm is a careful
and knowledgeable programmer, but if you are using ZAP, you've already
switched to ZAPwiki's security model whether you know it or not.

Anyway, not trying to stir the pot, so to speak, but to encourage some
hard thinking. Yes, of course, you have my full support and my help
anyway I can. But before you put too much effort into ZAP, it might be
worth it to really think through your bigger strategy. And come up
with a plan first. It might help.

Cheers,
Dan



More information about the pmwiki-users mailing list