2007/4/11, 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;">
(...)<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Thus, I suggest to spend a bit more time defining and freezing a standard
<br>> syntax and perhaps, write "test scripts" to test it automatically for every<br>> new version.<br><br>Can you give me an idea what you mean by this? I'm thinking better<br>would be simple upgrade instructions, like search "emailnews" and
<br>change to "email_news".<br>Or perhaps an announcement list? A beta and standard release version,<br>like PmWiki does? Well, let's hope this will be the last significant<br>change for a while...</blockquote>
<div><br>Currently, there are several ways to write some ZAP commands. Example:<br>(:zap datapage="{$:MyPage}":)<br>(:zap datapage='{$:MyPage}':)<br>(:zap datapage={$:MyPage}:)<br>For the previous example, all 3 may work but for more complex expressions (and in particular for conditionals), I think it is necessary to have a syntax "guaranteed to work" because sometimes, the only way to get a script to work is by trial and error. I also think that conditionals should output a message if the test result is empty to facilitate debugging.
<br><br>The test scripts would use of the reference syntax and allow to automatically check that each elementary functionality is working properly after a new release.<br><br>As far as the upgrade instructions are concerned, I would prefer the syntax to converge for good at one point not to have to go through all my scripts to see which ones are using the entry that has been updated. That would also cause a lot of extra work to keep the documentation, tutorials and the snippets up-to-date. I really suggest you think about each functionality and freeze the syntax step-by-step (which still allows you to change the way you program the relevant operation).
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> As far as the new extra functionalities are concerned, I would prefer to<br>
> consolidate and contribute to the testing and debugging of existing<br>> functionalities before developing much more. There is already a lot with<br>> what you've done. As far as I'm concern, this would also give me the chance
<br>> to share with the community some useful scripts (I've got a multi-thread<br>> forum running, password reminder, email validation, etc).<br><br>If you send me some of those I can put them up as snippets and handle
<br>the upgrades...</blockquote><div><br>I've got some scripts still using zapdata, others with the previous time markup, etc. Moreover, there are pieces of code a bit everywhere in some pages, footers, etc. With the new release, nothing is working anymore (Hahaha) ! That's no big deal because, just like you, I'm still trying to find the best way to put everything together for my projects but I'll need more stability when I go into production.
<br>As far as the scripts I'm talking about are concerned, I will update them with the reference syntax, translate them in English and document them as soon as it has converged. If you want, I can also give you admin rights on my "R&D" wiki ;)
<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 would also suggest you group extensions by the level of stability and by
<br>> the level of potential "danger" for the installation. Your proposals could<br>> have very useful applications but you don't want a new user to mess up his<br>> whole installation (or perhaps another site on the farm) with such
<br>> functionalities.<br><br>This is a good idea, and I hope the ZAPConfig system will help with<br>this. But I have decided against the multiple file downloads. I want<br>to try and just stick to two files.</blockquote>
<div><br>Yep. That's another good way of doing it. You could provide beginners with a ZAPConfig page disabling the "dangerous" features. <br><br></div>Another idea: the messaging system could be improved by discriminating
2 types of messages : user-directed messages (ex. : please fill in the
field "Name") and admin-directed messages (ex. : Form posted. Values
saved.). Admins would see all messages when validating and users would
only see user-directed messages.</div><br>Cheers,<br><br>Benoit<br>