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

[The Editor]

On 10/4/06, Crisses <crisses at kinhost.org> wrote:
> On Oct 4, 2006, at 2:59 PM, The Editor wrote:
>
> 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.

Actually I set a cap for myself of 500 lines.  3.0 is still under,
just barely.  But by creating more functions.  It is no smaller, but
no bigger--and much better!

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

Not even sure what that means (by reference?), but I would definitely
love to have input from others.  I like what I can do with FAST data,
but I'm sure parts could be done better.  Right now I have the
functionality.  I would like to boost performance.

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

Thanks!  It's been fun learning.  But now that I've got the hang of
it, I'm hungry to learn more. Also, it should be noted, there have
been MANY people on the list that have helped along the way.  A
special thanks to Pm who has been tireless in answering my questions.

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

Yes, I've barely had time to keep up with the ideas as they've
come--much less document, demo, and sample the various possible
applications.  I'm hoping to settle down now.  I thought I was done at
2.0, but Nils and Martin really sparked some inpiration that I had to
get into FAST Data.  If things do slow down I will get more samples up
(applications).  And as for the documentation, though it may not be
detailed, it is fairly complete.

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

I only did that to demo what it could do as a CMS.  But sometime back
rewrote the demo site so no login is necessary for most features, and
also to publish guest account info admins could use to log in.  Not as
much fun, but, it's quite open now.

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

Yes, I may experiment around with that. Not really sure how that would
work.  Maybe for a future release if I can find an easy way to make it
work.  If I can release it without having to break current forms, I'll
add it along the way.  Also, I need to figure out how to set up the
download so it will auto install everything in the right subfolder--no
clue how to do that.  Or just put the various downloads all in
cookbook. I'm only thinking maybe 2-4 extra plugin plugins.

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

How do you set up a "folder" for download?

> 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.]

Zip is growing on me.  Maybe I should thank Ben for inspiring me to
rethink the name?

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

Hehehe.  I hope it can get by the list "name-screening committee".

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

Well it does run fairly fast (zippy) still, but I was thinking fast in
terms of quick to install and quick to get using.  Download.  Then cut
and paste.  Instant functionality.  I'm thinking from an admin
perspective.

Also I'm thinking from the perspective of someone like myself who
wants a powerful site, but is (was) not a coder.  It should be no more
difficult to learn the FAST Data syntax than PmWiki markup.  Those two
things would enable him/her to do about all that was wanted.

Thanks for the feedback Crisses!

I'll be out of town this weekend again, so 3.0 will have to wait till
early next week.  I think I have it about done, but want to do more
testing to have something solid before I release it.

Cheers,
Caveman