[pmwiki-users] Conceptual challenges from ZAPwiki...

The Editor editor at fast.st
Thu May 31 17:11:21 CDT 2007


Just wanted to post a follow up regarding the initial beta release of ZAPwiki.

Without trying to sound like I'm promoting it here, I do think it
could be of real benefit to the PmWiki community to have a few folks
look at it, as it offers some radical ideas and innovative features
that could perhaps be incorporated into PmWiki. I started it as an
experiment to see if changing a few fundamental assumptions in PmWiki
could make a difference in how a wiki worked, and actually found the
results quite shocking. So as a proof of concept model--it offers a
challenge to PmWiki on a conceptual level worth discussing on this
list. At least I'd like to explore some of the issues here, if there
is any interest.

Though the code is virtually all new, it enjoys many philosophical
similarities with PmWiki.  But also some huge differences, summarized
here:

1. Easy installation and configuration. ZAPwiki comes as a single
zipped folder with about a dozen small scripts, including a setup.php
file which can be run to automatically create a new fully configured
ZAPwiki farm field. It can also be used to extract any other wiki that
has been backed up using ZAPwiki's built in backup function. This
means a designer could put together a full designed "bundle", export
it, and make it available as a single file you download and extract
via the setup script. Two seconds later, your wiki is ready to go.
It's an extremely simple script (esp with ZAPwiki's design), but
surely something like this could be implemented in PmWiki.

2. Page formats in PmWiki are fairly complex with various attributes
and history information stored in them. ZAPwiki uses straight text
files. (data values are used for any desired attributes, diffs stored
elsewhere). Meaning I could drop a txt file into my "pages" folder
(assuming it had an acceptable page name), and instantly pull it up in
my browser. Just that simple. Likewise, I can edit wiki pages in any
text editor I like, resave them, and they are good to go. It also
makes importing and exporting txt files a breeze. (ZAPwiki has both
built in). And as the markups honor leading spaces, tabs, and line
breaks (similar to Hans' brilliant LWS recipe), it makes it a snap to
take content from the textbox to the page and back again. It displays
it just like you type it in. Unless you've wrestled with the inner
workings of PmWiki file formats (the reason for the long delay in Pm's
commenting system), you won't appreciate how nice this is. It cut out
nearly 50% of the code in the ZAP toolbox if that gives a clue!

3. The entire skin is controlled within the wiki. That is all skins,
styles, javascript, etc., even php code, can be edited right within
the wiki. There is a PmWiki recipe that mimics this--but in ZAPwiki
it's built in, allowing for a very streamlined code engine. Meaning I
can customize the site however I want, whenever and wherever I want.
There were some tricky problems at first, but they were solved with a
few clever ideas--that proved quite handy. For example, a diagnose
action lists all the page zones, the pages used in each (all fully
hierarchical), and links to edit each. Code pages are automatically
identified and escaped (displayed) exactly as typed. Meaning I can put
a real html or css page right in my wiki and it will work. (Apart from
very simple markup for definining the Zones). And remember, everything
is fully hierarchical (natively, unlike Hg/Cluster) meaning you can
setup whole sections of your site with completely different skins,
add/remove zones, etc--and do it all within one folder of wiki pages.

4. And the big idea that started it all--the wiki engine itself is
essentially built within the wiki as well. That is, all site actions
are actually just simple ZAP forms. Meaning the code is in the
field--not the barn. Or to put it differently, I am not locked into
PmWiki's way of handling anything--I create, modify, or delete site
actions just as easily as I can write markup in a page. So I don't
need a bunch of plugins (though it has full plugin and local config
capabilities)--I just create a wiki page with a custom action. To
illustrate the point, ZAPwiki starts off with about 30 custom actions
such as member and group account creation and management, emails,
newsletters, posts (forum & blog), comments, data handling, backups,
logging, create pages, delete, undelete, edit, rename, search, etc.,
and a really cool sandbox. All of these can be modified in countless
ways however you want. This is really the secret to the conciseness of
the code--it's all done within the wiki. A whole new paradigm--and
it's powerful. Oh, and because the wiki engine is designed for ZAP,
countless problems I had in PmWiki that required complex workarounds
simply evaporated. Right out of the gate, there's no question in my
mind that on the form's processing side at least, what ZAPwiki can do
is head and shoulders above what ZAP can do in PmWiki.

There are many other innovative ideas in ZAPwiki, some of which really
should be ported back to ZAP. But you will have to check it out for
yourself for a more complete list of them. Happy to answer any
questions or discuss ways to use some of these ideas in PmWiki if
there's interest. I want to reiterate PmWiki is still superior
software, has a fantastic maintainer and wonderful support community.
ZAPwiki at best is a beta, at worst an experiment. I've not noticed
any bugs and really battened down the hatches on it security wise, but
I'm not willing to even claim basic stability/security at this point
for ZAPwiki. Give it some time to see if it explodes before trying it
on anything important. I'm especially still researching security
issues. But if you like to tinker, it might be worth exploring.

The download and some sketchy documentation can be found at
www.zapwiki.org, running ZAPwiki of course. It's just over 50K, and it
contains everything you need including all the code, and an entire
backed up pre-configured wiki! Yes, the whole download is about 40%
smaller than pmwiki.php all by itself.

Cheers,
Dan



More information about the pmwiki-users mailing list