2007/4/10, The Editor <<a href="mailto:editor@fast.st">editor@fast.st</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well maybe not so much philosophical as practical, but I have been<br>thinking about a number of issues and thought I would post my<br>contemplations and see if anyone has any feedback.<br><br>1) I'm really interested in making ZAP easier for users to install and
<br>use. It's not uncommon for a significant application to use four or<br>five modules. ZAP, ZAPextend, markups, conditionals, etc.<br><br>I'm wondering if I shouldn't just have two: ZAP and ZAPextend<br>(containing everything else divided into commented sections). An
<br>advanced admin would then simply cut and paste the ZAPX functions, and<br>any related markups functions or conditionals to the config pages<br>where they would be used. And ZAPextend would never even really need<br>to be enabled. It might also encourage more customization as that is
<br>no SO easy to do...<br><br>Someone less inclined to tinker with their config files would just<br>enable two recipes (where needed) and have everything available to<br>them. To enhance security for such a set up, I've been thinking of
<br>adding a few lines to the main ZAP engine that would check for the<br>existence of a Site.ZAPConfig page, and if it existed, look for a<br>defined list of Groups/Pages where that command is allowed before<br>empowering that extensions/markups, etc. That would make it very easy
<br>to maintain good control of what ZAP can do and where.<br><br>Any input on the performance drag of just defining 15-20 functions<br>(300-400 lines of code) that are rarely used? Or this approach in<br>general?</blockquote>
<div><br>As far as I'm concerned, I like your idea to visualize and control the recipes from the ZAPConfig page. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) To make it easier for users to setup ZAP forms on their site, I'm<br>still toying with the idea of a ZAP super markup--something really<br>simple, perhaps like ZAP->Login or even ZAP:Login which would retrieve<br>
a complete ZAP form from a template page and insert it into a page<br>ready to go. Something like a pagelist template.<br><br>In this case we could make available a cut and paste list of favorite<br>forms (login, register, profiles, email, subscribe/unsubscribe,
<br>newsletter, forum, comment, shopping cart, paypal checkout, instant<br>messages, chat) and then any of the desired functionality could be<br>inserted into a page or groupfooter instantly.<br><br>Can you imagine creating a fully functional, styled forum by adding
<br>one or two commands to couple groupfooters? If combined with Hg, the<br>possibilities are amazing...</blockquote><div><br>For the moment, I'm using the (:include:) entry to do this and it works very well. As far as I'm concerned, I don't really see the added value of an extra "super markup".
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3) In working on the ZAPcart module (which required a bit more<br>sophisticated programming than the earlier version, I began to realize
<br>most things can be done directly in a recipe without having to have a<br>bunch of separate recipes.<br><br>Rather than bunches of separate files for complex applications, with<br>careful planning, things like CSS, pagelist templates, & javascript
<br>can be embedded via the php recipe. Similarly, instead of thinking of<br>both conditionals and markups, why not rewrite conditionals as<br>markups? For example (:if {(inlist {$AuthId} {$:MyList})}:) would be<br>equivalent to (:if inlist {$Authid} {$:MyList}:) if that markup
<br>returned just true or false. So I could drop ZAPconditionals, and just<br>have a bunch of ZAPmarkups!<br><br>In other words, I'd like to condense the kinds of things a person<br>needs to know down to the barest minimum so users don't have to worry
<br>about learning so much... ZAPextensions and ZAPmarkups. (Pm should<br>be releasing his version of the {( )} recipe soon. If not I will<br>modify what I already have and release it to make it just as<br>extensible as ZAP, and probably move it into the ZAP core. I love
<br>those markups! Makes so many things easy... <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4) Perhaps ZAP has too voracious an appetite, but I have thought of a
<br>new area to grow into. Namely, bursting the limits of PmWiki. With a<br>few changes to the code, ZAP could create it's own alternate page<br>read/save model. That is, by using some base PHP functions rather<br>
than base PmWiki functions, I could generate a ZAP list display (ie<br>pagelist) of all the txt files in a given directory on the server--and<br>rather easily import them into wiki pages. Or vice versa, open a<br>selected group of wiki pages and export them as text documents
<br>(perhaps in rendered html).<br><br>It could be used to create text logs, or edit htapsswd files, and<br>probably various other things. What about exporting all the pages of<br>an entire group into a single extended text document? Or perhaps even
<br>a pdf? I plan to use it for ZAPchat to create ajax driven text based<br>chat histories and completely bypass the PmWiki rendering engine.<br>(Doesn't anyone have an ajax recipe I could tinker with?)</blockquote><div>
<br>I am really impressed by your tool and the pace at which you progress. Yet, I must say that versions are changing very fast and there are some pretty important changes in the syntax every time. For me, that's a very big problem because I've got a couple of websites running on my farm and when I update ZAP, I can't re-test every script of every installation. This has not been a too big problem but from now on, I'm going to need more stability if I want to use the recipe on interactive production sites.
<br><br>Thus, I suggest to spend a bit more time defining and freezing a standard syntax and perhaps, write "test scripts" to test it automatically for every new version. <br>I support a syntax consistent with the one defined for pmwiki pagelist. Even if it is a couple of letters longer, it is consistent and - in my opinion - much clearer.
<br><br>As far as the new extra functionalities are concerned, I would prefer to consolidate and contribute to the testing and debugging of existing functionalities before developing much more. There is already a lot with what you've done. As far as I'm concern, this would also give me the chance to share with the community some useful scripts (I've got a multi-thread forum running, password reminder, email validation, etc).
<br><br>I would also suggest you group extensions by the level of stability and by the level of potential "danger" for the installation. Your proposals could have very useful applications but you don't want a new user to mess up his whole installation (or perhaps another site on the farm) with such functionalities.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I do realize of course this is a bit dangerous route to go. With ZAP<br>already able to create, edit, delete pages, and about anything else
<br>you can think of doing with a page, it is getting closer to the time<br>it can function with or without PmWiki! When I started creating ZAP,<br>it dawned on me a good form processing engine was the primary thing<br>needed in a web management system--for all user interaction,
<br>ultimately is through a form. Little did I guess where that idea<br>would lead at the time, but ZAP's little 100 line engine is raising<br>some interesting questions in my thinking. Philosophical indeed.<br><br>
Cheers,<br>Dan</blockquote><div><br>Thanks for this amazing work. Cheers !<br><br>Benoit <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
_______________________________________________<br>pmwiki-users mailing list<br><a href="mailto:pmwiki-users@pmichaud.com">pmwiki-users@pmichaud.com</a><br><a href="http://www.pmichaud.com/mailman/listinfo/pmwiki-users">http://www.pmichaud.com/mailman/listinfo/pmwiki-users
</a><br></blockquote></div><br>