<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Oct 5, 2006, at 10:59 AM, Ben Stallings wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">The reason I have misgivings about "ZipData" -- and I guess I'm on the<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">name-approval committee ;-) -- is that if your recipe has multiple<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">files, the most likely way you'll distribute them will be in a .zip<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">file, hence Chrisses's comment about admins "unzipping" the file before<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">uploading it to the server.<SPAN class="Apple-converted-space"> </SPAN>Back in my tech-support days I literally<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">spent hours explaining to users the difference between a Zip disk and a<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">.zip file.<SPAN class="Apple-converted-space"> </SPAN>Fortunately Zip disks are largely irrelevant now, but .zip<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">files are still with us, and I wouldn't wish that particular problem on<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Comic Sans MS" size="3" style="font: 12.0px Comic Sans MS">anyone when there are so many other names available.<SPAN class="Apple-converted-space"> </SPAN>:-)</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>This is a good point --</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>To me "ZipData" sounds to me like a recipe that allows me to .zip the contents (data) of a number of pages in the wiki (not a bad idea for a recipe anyway!).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>i.e. "this recipe will zip your data."</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Another thing that's important to keep in mind: Namespace. I've been trying to keep the vast bulk of my (newer) cookbook recipes within a function or class. The problem is that every time you create a variable you risk bumping into conflicts between your variable name(s) and those of other recipes. This also goes for function names.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The function name "Data" is not a good function name, I have to say. If you kept "FASTData" and prefixed all your (global scope) variables and function names with "FD_" then it would be much safer. So another suggestion is to change scope even if you then require a global statement to pull info in &/or rename global functions and variables to have ZD if you do name it ZipData -- or whatever. It lessens the chance of conflict with other recipes.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>AuthUserDBase is using AUD_Function() and $AUDBase_Variable (etc) and when I wrote my extension, one reason I used XES in the name is because I am using XES in the actual program to be pretty darned sure I'm not going to conflict with other recipes or PmWiki's core variables/functions.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Once your function is defined, your namespace is local instead of global. The same goes for objects/classes. Much safer in a shared programming environment.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A good example of code that should be in an included file for your recipe is the FastData->Database functions. I also highly recommend that you follow the discussion of encouraging cookbook cooks to use adodb instead of writing code for a single type of database. In any case, not everyone is using a database, and the code may be pretty long. If they don't have adodb called before your recipe, your recipe might even break because your database functions are calling on functions / classes that are not defined. If it's in an include, you can check that adodb was loaded AND that the code is needed before loading the database functionality. That could save another 500 lines of code from being called. ;)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Crisses</DIV></BODY></HTML>