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

[Crisses]

On Oct 4, 2006, at 2:59 PM, The Editor wrote:

> FAST Data 3.0 is rolling around soon, and while not adding many new
> features, will be significantly reworked in terms of code to 1)
> enhance flexibility (notably csv list handling and templating), and 2)
> dramatically strengthen known security issues. There will also be some
> ease of use improvements.
>
> Here's some questions for any list members with an interest in this  
> project:
>
> Though I have not yet noticed any performance problems, a couple of
> individuals have questioned whether or not this recipe is a massive
> victim of feature creep. (Or is it just "full-featured"...).

I took at least a cursory look at your code.  More, because I used it  
as an example for a recent hack I did, and I've had to alter your  
code a couple times...

I think you're providing tools.  Not every use is going to use every  
tool.  If someone builds a monstrous application with your tools,  
then it's going to run like it is a monster.

If someone builds a lightweight app like I did then it's not going to  
run like a monster.

Last I looked it was about 500 lines of code... including comments  
and intro.  As you get better and consolidate your code, pull out  
common code into single functions, etc. it may get smaller and better  
rather than bigger... we'll see.

As for how it runs: if any more senior programmers -- myself included 
(?) -- decide to take a look at it and give you pointers on smoothing  
out the flow, saving memory, speed tips, etc. I'm sure that you won't  
say no.  You may not know every built-in function in PHP, or that  
calling variables into functions by reference is faster and saves  
memory. (PM reminded me of that last night -- oops)

Note, pmwiki.php is 1800 lines, with only 5000+ supporting lines in / 
scripts/ ;)  And I'll tell you right now -- most of that is NOT  
commented LOL

Honestly --> pmwiki is packed tight.  500 lines for a new programmer  
and accomplishing what you're doing is great.

What we need are examples NOT on your site -- very simple monkey-see,  
monkey-do examples that people can follow along with and the LOGIC  
explained.  Not just cut & paste, but show off why it's cool.  Then  
we can make suggestions to improve your code and use -- and there  
will be a 4.0 in the future.

>   Anyhow,
> I'm not sure how to solve this--as most of the features make use of
> the same set of functions, and keeping it all together allows an
> author to perform multiple actions as well. IE, create a new member
> account, email a verification message, and authenticate them in one
> shot.  Or enter a csv list of page names, create the pages with data
> extracted from their profile, and save them. For things like forums,
> instant messaging, file management, etc., this combo thing is really
> nice.

Yes, but it's one thing to talk about it, and to tell people it's  
great, and another to give an example -- walk people through, or  
create a tutorial.  One thing I've balked at is the need to register  
to see what you're doing.  Can you make the reveal code visible  
without login? (it's on the Triad skin...?)  I'm not interested in  
needing to track another username & password to get at the examples.   
Or put examples in a group on PmWiki, and ask PM to enable the script  
for that group.

> One solution is to leave as is, and suggest users simply delete out
> any functions they don't want (my original thought).  Second solution
> is to put the less used functions at the end, commented out, and have
> authors cut and paste them into the data engine (at a point indicated)
> to add those specific functionalities.  A third option might be to
> break it up into several recipes, and dynamically include them as they
> are needed into the main recipe (is that possible?).  Something like:
>
> if (field == "email") {
>      include data-email.php;
>      email($value);
>      }

You can have a sub-folder of include files.
/cookbook
	data.php
	/data-files
		data-email.php
		...

The only problem is getting them included correctly when the script  
is running.  But in this way, it only loads the code it needs (and  
it's easier to write if it's split into different files because you  
save a lot of scrolling and split-screen editing ;) ).

Then yes, include_once only what's needed.  (not include if you're  
defining functions! or check if the function is defined before  
defining it)

> Of course all this (except the first option) goes against the design
> goal of having a powerful forms processing engine that would easy to
> install and use without needing to know php.  Just drop it in the
> cookbook, add a line or two to your config, and you are ready to go.
> Any thoughts on the right balance?

Yep.  They unzip, drop a file & a folder in the cookbook folder, add  
a line or 2 to the config, and they're ready to go.

YOUR end does the include(); statements.

That makes it no harder than pmwiki to install & if you write good  
tutorials, no harder to use...

> Lastly, I'm thinking about changing the name to ZipData for various
> reasons. Once the major development is over I want to start adding
> recipes based on specific applications of this that could be called
> things like ZipBlogs, ZipForums, ZipMessaging (I have this on my
> site--and it is really awesome), ZipFileManagement, ZipCMS, etc.
> These would all be based on the core recipe, but include cut and paste
> snippets with instructions for the best ways to set these kinds of
> features up.  Any thoughts?

A common prefix is good -- not sure about "Zip" -- but it's short,  
sweet and doesn't conflict with Xes ;) LOL  [if anyone has missed  
that one, xes is to Crisses as xmas is to Christmas.]

Does "Zip" have a religious affiliation?  Is it a God in the  
Zoroastrian religion?
Inquiring pagans want to know. ;)

Just kidding.

How about Flex?  -- you wouldn't want it called Zip or Fast (or FAST,  
for various reasons), and have it turn out SLOW ;)  Flex as in  
flexible is really what you're trying to be.  You say it's fast, but  
not that many people have picked up your idea all that fast ;)

Crisses