[pmwiki-users] ZAP philosophical questions

Ben Stallings ben at interdependentweb.com
Tue Apr 10 10:15:06 CDT 2007


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

Since DataPlates requires all four, I'm in favor of any reduction in the 
number of files admins need to individually download and install. 
Here's an option that you didn't mention, that combines ease of 
installation with a reduction of the number of lines of code included. 
It's a similar scheme to that used by Triad Skin or ADOdb, or for that 
matter the one currently being discussed in the "extra guidelines for 
recipe publishing" thread.

1) Package all the ZAP files together (including the modules) in a .zip 
file.  An admin would simply unzip this in the Cookbook directory. 
There will be some files the site will not use, but so what -- they're a 
few hundred KB.

2) The admin need only include zap.php and specify which functions to 
use (or not to use) in config.php or in the ZAPconfig page.  My 
preference would be to have all the markups, conditionals, etc. enabled 
by default and all the modules disabled by default, but my preference is 
just based on my own usage patterns.  :-)

3) zap.php includes the other files *as needed*.  That is, if a given 
function is enabled, the file containing it is included; if not it it 
not.  You could get really fancy and only include those files if a 
function is called (by a Markup function), but I think that may be going 
a little overboard.  And/or split up the existing files into individual 
files for each function, so that disabled functions never get installed.

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

Again borrowing a trick from Triad Skin, why not include in your package 
a wikilib.d directory for pages like Site.Login and 
ShoppingCart.GroupFooter?  Then there's no need for additional markup -- 
the pages just appear in the proper places, and can be customized by 
regular editing.  If an admin doesn't want to use some of the pages, she 
can just delete or remove them from that directory.

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

I sympathize, having run into some limitations myself, but the more I've 
learned about PmWiki, the more I respect the reasons for the limitations 
and the value of not bursting them.  Most of us are here because PmWiki 
is a stable, safe, user-friendly structure on which to build sites.  If 
ZAP gets so powerful that it makes PmWiki unstable or insecure or 
unfriendly, it will sabotage its own reason for existence, which is (as 
I understand it) to process forms for PmWiki sites.

I think so far you've done a commendable job of working with the list, 
asking for suggestions, accommodating more standard markup, etc. but 
when you say, "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!" you run the 
risk of leaving us behind.  If we wanted to do without PmWiki we would 
not be here.  There are other, more stable, more friendly programs 
available to process forms, if that's all we wanted to do.

To give an analogy from my own experience, when I wrote SelectQuery and 
UpdateForm last year, I didn't work with the group.  I went off on my 
own and wrote recipes that worked outside the PmWiki framework and just 
used PmWiki to display their results.  The result was functional and 
fast, but it relied on nonstandard markup.  Pico steered me onto the 
path I've been pursuing ever since, when he suggested that database 
records could be treated as wiki pages, and ZAP has allowed me to 
piggyback on much of the work you've done, Dan, and get rid of 
essentially all of my custom markup.  But if ZAP leaves PmWiki behind, 
where will that leave DataQuery?

That said, I think there are important things that you can do outside of 
PmWiki, such as listing & working with files outside the wiki structure 
-- I'm thinking particularly of deleted pages.  For my part, I need to 
write my own replacement for pagelist to work intelligently with 
database queries.  But if you're looking for support from the PmWiki 
community, PmWiki needs to stay at the center of what you're doing! 
That's my opinion.

Thanks for all your hard work, Dan!  --Ben



More information about the pmwiki-users mailing list