[Pmwiki-users] Request for method to let plugins execute code after stdconfig.php

Patrick R. Michaud pmichaud
Fri Jul 16 06:45:57 CDT 2004


On Fri, Jul 16, 2004 at 11:48:39AM +0200, Christian Ridderstr?m wrote:
> 
> I'm helping John with his work on page drafts, and he's got some
> difficulties in making the plugin do all that he wants. Basically I think
> he needs to let the code modify some variables after stdconfig.php, or
> possibly after other plugins, have done their job.
> 
> One solution could be to use a 'hook'-class I wrote a while back. 
> [...]

Well, let me give two answers--first, an overall comment about the
principles behind the hook scheme, and second, some thoughts on an
implementation.

Thus far I haven't been completely convinced that hooks can really
solve the problem that's trying to be solved, and they may introduce
more complexities and issues than they're worth.  Essentially, hooks
are a way of letting a module say "I want a chance to be last".  But
only one module can be last.  So, while hooks do give modules a chance
to do things after stdconfig.php has run, how do we sequence hooks
between multiple modules?  And what happens when we move recipes with
hooks into stdconfig.php -- aren't we pretty much back where we started?

I totally understand the desirability of being able to say 
include('somemodule.php') and have everything "just work" regardless
of what other configurations/modules have been loaded.  But I don't
think hooks get us there, and I worry that a halfway solution like hooks
may actually be worse than no solution at all, because it adds another
layer of control that has to be considered when trying to figure out
why things don't "just work".

However, IF we assume that hook routines never pose any conflicts--
i.e., no hook routine will ever depend on configurations made by
something done in another module's hook routine, then I can see how 
hooks would be useful.  But instead of the code proposed, I think
there are some simpler approaches that are equally effective and
more easily understood/usable by module writers.

For example, why the overhead of a class and object?  Arrays work just
fine for this--and PHP has lots of built-in functions for manipulating
arrays.  So, instead of $after_stdconfig_hook->append('myhook'), why
not just do

    $ConfigHooks[] = 'myhook';

This is much more consistent with the way other things are done 
in PmWiki configuration.  Stdconfig.php then simply does 
foreach($ConfigHooks as $f) $f();  to execute all of the hooks.

Another approach:  we already have "include_once", why not create an
"include_after" function to specify modules to be loaded after all
of the others?  Then one could do:

    include_after('drafts.php');

which does the include but postpones it to occur at the end of
stdconfig.php.  If multiple include_afters are specified, the files
are loaded in the order that the include_after calls were executed.

(This last example illustrates why hooks won't completely solve the
problem--even with something like "include_after", there's still the
possibility that two or more modules using include_after will
have dependencies between then, and so something--usually a person--
has to be smart enough to know which goes first.)

Responses?

Pm




More information about the pmwiki-users mailing list