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

[The Editor]

Oops.  Meant to send this to the list again!  Haha.

On 10/4/06, Joachim Durchholz <jo at durchholz.org> wrote:
>  > Caveman wrote:
> >> 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.
>
> This sounds like premature optimization to me.
> PHP parsing times aren't very high - not in comparison to running PHP
> code anyway. I wouldn't worry too much about that before hitting the
> 1,000 lines of code barrier.
>
> Inefficiencies in the code are a much more interesting field for
> optimization.

I'm not sure whether PHP is parsing or running in the FAST Data
engine, but it seems to be doing a lot of running as it is using a
bunch of conditionals to trigger all kinds of functions.  Actually,
the engine is really an interface between PmWiki and PHP.

But the 1000 line code barrier sounds great!  I was thinking about
adding a (:log:) directive to simplify incorporating comment boxes in
a page (rather than using includes).  And I have the code for a
approve/ban list process that would only allow certain users to do/not
do given form submissions.  But it would break the 500 limit.  These
two would add about 20-30 lines.  Maybe I should just do it.  If I
don't count the blank lines and commented lines, I bet it would still
be under 500 lines of "code"...

Well, I talked myself into it.  Two more things.

>  >> 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?).
>
> Yes.
>
> You can even put most kinds of declaration (functions, global/static,
> etc.) inside an "if" statement; the declaration will take effect only if
> the condition holds.
> However, I say that only to show the flexibility of PHP. In practice,
> it's usually not a good idea, at least for functions, because that
> breaks some caching mechanisms that may be installed on the server for PHP.
> You can even include a file from within a function. That's rarely done
> however, and probably not well-supported (i.e. likely inefficient);
> besides, it has ramifications for variable scope.

Sounds a bit complicated. Maybe I'll wait and see how necessary it is.

>  >>  Something like:
> >>
> >> if (field == "email") {
> >>      include data-email.php;
>
> Don't forget the quotes:
>          include 'data-email.php';
>
> >>      email($value);
> >>      }
>
> On naming: DataPage might be good enough. Abbreviate to DP_whatever.
> Zip and Flex and whatever are all nice and dandy, but they don't *mean*
> a thing, resp. don't properly describe what the recipe is doing.

I still like zip.  : )  See my note to Crisses about the zippiness of
setting up a zip function for admins.  Thanks for the input Jo!

Cheers,
Caveman