[pmwiki-users] ZAP philosophical questions...

The Editor editor at fast.st
Mon Apr 9 21:35:25 CDT 2007


Well maybe not so much philosophical as practical, but I have been
thinking about a number of issues and thought I would post my
contemplations and see if anyone has any feedback.

1) I'm really interested in making ZAP easier for users to install and
use.  It's not uncommon for a significant application to use four or
five modules.  ZAP, ZAPextend, markups, conditionals, etc.

I'm wondering if I shouldn't just have two:  ZAP and ZAPextend
(containing everything else divided into commented sections).  An
advanced admin would then simply cut and paste the ZAPX functions, and
any related markups functions or conditionals to the config pages
where they would be used.  And ZAPextend would never even really need
to be enabled. It might also encourage more customization as that is
no SO easy to do...

Someone less inclined to tinker with their config files would just
enable two recipes (where needed) and have everything available to
them.  To enhance security for such a set up, I've been thinking of
adding a few lines to the main ZAP engine that would check for the
existence of a Site.ZAPConfig page, and if it existed, look for a
defined list of Groups/Pages where that command is allowed before
empowering that extensions/markups, etc. That would make it very easy
to maintain good control of what ZAP can do and where.

Any input on the performance drag of just defining 15-20 functions
(300-400 lines of code) that are rarely used? Or this approach in
general?

2) To make it easier for users to setup ZAP forms on their site, I'm
still toying with the idea of a ZAP super markup--something really
simple, perhaps like ZAP->Login or even ZAP:Login which would retrieve
a complete ZAP form from a template page and insert it into a page
ready to go.  Something like a pagelist template.

In this case we could make available a cut and paste list of favorite
forms (login, register, profiles, email, subscribe/unsubscribe,
newsletter, forum, comment, shopping cart, paypal checkout, instant
messages, chat) and then any of the desired functionality could be
inserted into a page or groupfooter instantly.

Can you imagine creating a fully functional, styled forum by adding
one or two commands to couple groupfooters?  If combined with Hg, the
possibilities are amazing...

3) In working on the ZAPcart module (which required a bit more
sophisticated programming than the earlier version, I began to realize
most things can be done directly in a recipe without having to have a
bunch of separate recipes.

Rather than bunches of separate files for complex applications, with
careful planning, things like CSS, pagelist templates, & javascript
can be embedded via the php recipe. Similarly, instead of thinking of
both conditionals and markups, why not rewrite conditionals  as
markups?  For example (:if {(inlist {$AuthId} {$:MyList})}:) would be
equivalent to (:if inlist {$Authid} {$:MyList}:) if that markup
returned just true or false. So I could drop ZAPconditionals, and just
have a bunch of ZAPmarkups!

In other words, I'd like to condense the kinds of things a person
needs to know down to the barest minimum so users don't have to worry
about learning so much...  ZAPextensions and ZAPmarkups.  (Pm should
be releasing his version of the {( )} recipe soon.  If not I will
modify what I already have and release it to make it just as
extensible as ZAP, and probably move it into the ZAP core.  I love
those markups!  Makes so many things easy...

4) Perhaps ZAP has too voracious an appetite, but I have thought of a
new area to grow into.  Namely, bursting the limits of PmWiki.  With a
few changes to the code, ZAP could create it's own alternate page
read/save model.  That is, by using some base PHP functions rather
than base PmWiki functions, I could generate a ZAP list display (ie
pagelist) of all the txt files in a given directory on the server--and
rather easily import them into wiki pages.  Or vice versa, open a
selected group of wiki pages and export them as text documents
(perhaps in rendered html).

It could be used to create text logs, or edit htapsswd files, and
probably various other things.  What about exporting all the pages of
an entire group into a single extended text document?  Or perhaps even
a pdf? I plan to use it for ZAPchat to create ajax driven text based
chat histories and completely bypass the PmWiki rendering engine.
(Doesn't anyone have an ajax recipe I could tinker with?)

I do realize of course this is a bit dangerous route to go. With ZAP
already able to create, edit, delete pages, and about anything else
you can think of doing with a page, it is getting closer to the time
it can function with or without PmWiki!  When I started creating ZAP,
it dawned on me a good form processing engine was the primary thing
needed in a web management system--for all user interaction,
ultimately is through a form.  Little did I guess where that idea
would lead at the time, but ZAP's little 100 line engine is raising
some interesting questions in my thinking.  Philosophical indeed.

Cheers,
Dan



More information about the pmwiki-users mailing list