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

The Editor editor at fast.st
Thu Oct 5 09:48:11 CDT 2006

On 10/5/06, Joachim Durchholz <jo at durchholz.org> wrote:
> The Editor schrieb:
> >
> > 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.
> Yes, but that applies to 90% of all recipes. It doesn't characterize
> what your recipe is doing.

Actually not too many recipes can do everything from an instant
messaging system, to blogging, to forums, to member authentication,
etc, all in one script.  The zip part is once the recipe is installed
all the features become available by simply cutting and pasting wiki
markup from one page to another.  Or, to put it differently, 90% of
the recipes can be duplicated by this recipe (at least those doing
anything with forms)--without having to install any additional
scripts.  To me that is kind of cool.

If FAST Data were included as an optional script in the default
distribution of PmWiki, most users might never have to install another
recipe, for anything.  And new features could be added just be writing
up a different forms markup.  That's even easier than the cookbook
idea.  Granted of course, FAST Data can't do everything.  But it does
do full-featured forms processing.

> On including just what's needed:
> Split the recipe into several include files. If include file a.php needs
> definitions from include file b.php, have a.php do
>    include_once ('b.php');
> somewhere.
> The above ignores subdirectory issues. I usually do something like
>    include_once (dirname (__FILE__) . '/b.php');
> to include a file that's stored in the same directory as a.php.
> With multiple include files that use each other, I usually end up with a
> couple of common files that are included from most of the others, and
> "feature files" that look like this:
>    <?php if (...) return; # check that pmwiki is running
>    include_once (dirname (__FILE__) . '/common.php');
>    function feature_1 (...) {...}
> Administrators then include just those feature files that they need from
> config.php, which in turn then include all the base machinery required
> specifically for them.
> Tend to keep the footprint of extensions low - *provided* that the
> administrator includes just those features that he really needs.
> The nice thing about this approach is that nobody needs to copy code around.
> Regards,
> Jo

In the recipe I'm using, it has something like this--with one "if" for
each available feature:

function Data() {
global $WorkDir, $WikiDir, $pagename, $ScriptUrl, $MessagesFmt, $m,
$ts, $data, $log;
foreach ($_POST as $field => $value) {
if ($field == "page") { ... }
if ($field == "create") { ... }
if ($field == "destroy") { ... }

Suppose I wanted to keep the page feature in the core engine, but put
the create and destroy functions into a file management include (a
secondary php file).  In the main Data function, I would somehow want
to not only trigger the include when needed, but also process that
post field properly.

I'm assuming I would basically have to transform the lines of code in
the conditional into a function (in the include file) and then have
the base recipe include the php file and call that function.  ie,
something like:

function Data() {
global $WorkDir, $WikiDir, $pagename, $ScriptUrl, $MessagesFmt, $m,
$ts, $data, $log;
foreach ($_POST as $field => $value) {
if ($field == "page") { ... }
if ($field == "create") {
if ($field == "destroy") {

I would also have to be careful to define the functions with all the
needed globals, etc, which should be available from the base recipe.
I am assuming all the functions in the base recipe would also be
available to the include functions and vice versa.  Am I understanding
you correctly?  Thanks for the ideas.


More information about the pmwiki-users mailing list