[pmwiki-users] Request input on soon-coming FAST Data release

Crisses crisses at kinhost.org
Mon Oct 9 03:07:14 CDT 2006


On Oct 5, 2006, at 10:59 AM, Ben Stallings wrote:

> The reason I have misgivings about "ZipData" -- and I guess I'm on the
> name-approval committee ;-) -- is that if your recipe has multiple
> files, the most likely way you'll distribute them will be in a .zip
> file, hence Chrisses's comment about admins "unzipping" the file  
> before
> uploading it to the server.  Back in my tech-support days I literally
> spent hours explaining to users the difference between a Zip disk  
> and a
> .zip file.  Fortunately Zip disks are largely irrelevant now, but .zip
> files are still with us, and I wouldn't wish that particular  
> problem on
> anyone when there are so many other names available.  :-)

This is a good point --

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

i.e. "this recipe will zip your data."

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.

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.

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.

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.

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

Crisses
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20061009/59652ea2/attachment.html 


More information about the pmwiki-users mailing list