[pmwiki-users] ZAP philosophical questions

[The Editor]

On 4/10/07, Ben Stallings <ben at interdependentweb.com> wrote:
> 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.

Yes I hadn't thought about that.  I kind of lean against the extra
step of zip & unzip though.  And if I just simplify things ZAP to
ZAPextend, not much point for zipping it...

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

Yes, I think that's probably right.  Though what I have in mind is to
make all extensions enabled unless theres a site config page, in which
case only those extensions that are specifically enabled would work.
I'll look carefully at the markups to see if some need to be
restricted as well, though probably most do not.

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

This is a little different from what I originally had in mind, but similar.
My idea was a page like this:

create:Test,Snippets.Create
delete:Test,Snippets.Delete

I think you're suggesting something more like

Test: create,delete
Snippets.Create: create
Snippets.Delete: delete

Now that I look at it the first instance seems easier...  (Both to
setup and to code)

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

A good idea, but it still seems easier to cut and paste (and edit) one
template page than to have multiple wikilib.d pages.  I suppose I can
even set up an install module that set everything up, including the
site config page by just running it one time. That's a cool thought.
Kind of: instant ZAP site.

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

Agreed, Pm has done a masterful job with PmWiki.  And if ZAP has been
a success at all, it's only because it's followed the suggestions of
Pm and others closely.  By limitations, I only meant ZAP *could* be
set up pretty easily to do a good number of things without PmWiki.
Only thinking out loud, as usual.

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

Eh, no intention of leaving the community any time soon.  Everything I
know about php I've learned right here.  It's been better than any
college course I could have taken!  And I'm VERY grateful.  Esp to Pm
for his many patient explanations of things. ZAP is my small gift back
to the PmWiki community--and its staying right here.  Still, just to
test it's limits, I do find myself curious about toying with a helper
script that could run ZAP by itself.

What other forms processing programs were you thinking about.  I'd be
interested in looking at some for ideas...

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

No worries, Ben.  ZAP will stay right here, as long as there are folks
interested in using it.

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

Certainly, and more than fair. Right now I'm committed to PmWiki.
There are some really great minds here throwing out ideas left and
right. It's exciting to be a part of something like this.

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

Thanks for your ideas above.  I'll try to get around to reworking a
simpler installation system sometime in the next week or two.  Looking
forward to Pm's {( )} recipe in the meantime.  Hopefully I can do a
joint upgrade that incorporates changes to the ZAP markups as well...

Cheers,
Dan