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

Christian Ridderström chr
Fri Jul 16 09:19:38 CDT 2004


On Fri, 16 Jul 2004, Patrick R. Michaud wrote:

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

I should be more clear about what I want to do I guess. In another mail
I've asked John to expand on his problem, and I give an example of for
what I'd like to use it.

Basically it's about letting a plugin make changes to the default values 
of variables created by stdconfig.php.  

> 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 think we could manage these problems. Right now the hook class only
supports 'prepend' and 'append', which only supplies a crude priority
mechanism. This could easily be made more advanced if we felt the need.

However, we always have this problem of executing plugins (and pmwiki
modules like stdconfig.php) in the right order :-( sometimes it can be
very annoying to make things work because of plugin dependencies.
OTOH, I can't really see a simple solution for this (it is a complex 
problem after all).
 
> [hooks] adds another layer of control that has to be considered when
> trying to figure out why things don't "just work".

I guess that's true. Maybe we can look at it differently. In my problem I
wanted to make a minor modification to some variable that stdconfig.php
created. This is typically some layout variable, where I for instance want
to add access keys to some links. Defining this variable yourself isn't a 
good solution for various reasons, but is there some way which I could 
call stdconfig.php in order to get *only* the default value?

Then I could define the variable like this:

	$SomeVariable = string_replace(get_default('EditTemplate'),
					someString, replacementString);

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

It was fun to write... and IMHO it makes the code more readable for people 
who are not experts in PHP. And in case priorities need to be added, it's 
easier to be backwards compatible if it's a class since the object 
interface may simply be augmented.

> Arrays work just fine for this [...]

Just out of curiosity, how do you prepend to an array?

--and PHP has lots of built-in functions

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

ahem, I'm not a PHP-expert...

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

Hmm.. I think you may still have problem with inter-plugin dependencies, 
i.e. plugin 'A' needs plugin 'B', but plugin 'B' really wants to modify a 
string that stdconfig.php defines. (or somethign like this).

OTOH, this might be a good solution for most of the problems I've had, I 
don't know.

/Christian

-- 
Christian Ridderstr?m                           http://www.md.kth.se/~chr





More information about the pmwiki-users mailing list