Ben Coburn wrote:
I was already starting to think about an "action hooks" extension so I'm very glad you wrote this. I have had time to read through the code now, so here are some thoughts on it.For clarification. A trigger event (currently) consists of three signals.
1) I think advise() should become advise_before() and advise_after(). Some plugins that rely on "advisory hooks" may need to know that they are running before or after the event that caused the "advisory hook". For example, assume there is an "advisory hook" that a page is deleted. Some plugins may need to access the page content *before* it is deleted, while others could run before or after the page is removed. This ensures that the plugin author knows exactly when the hook will be executed relative to it's event.
<event name>_before <event name> <event name>_after
2) How about adding a file (inc/events_list.php) to the source that is a big php comment documenting all the current hooks. Having a wiki page documenting the hooks is good but will it be in sync with the stable release, darcs, etc? Having a concise list of available hooks revisioned in darcs will allow programmers to know exactly what hooks are available in *any* version of the dokuwiki source that they happen to have. Example...I think a wiki page with this information should be enough. Having things in wiki also makes it much easier for others who don't have access to the codebase to improve the documentation. Having the information out of step in two places I don't think would be a good thing.
/*
name: EVENT_NAME
action: expanded description of the event that activates this hook
type: advise or trigger
data: description of data sent in the event
location: function name and source file from which the event is activated
comment: comments on possible usage, etc.
*/
3) Advisory events need to be completely advisory. Advisory events should not allow plugins to use preventDefault(). Code that activates advisory events should not check _default afterwards... (That is described as a private variable in the object anyway!) The cleanest solution is to split the "event" class into an Advisory_Event class and a Trigger_Event class. This will help enforce the meaning of advisory and trigger events.Actually they don't need to check _default - its the value returned by ->advise(). I've now altered the code for 'ACTION_TEMPLATE' to do this.
How about I redo the documentation and not claim two types of events.
Finally, maybe it would make sense to rename advise(), signal().
Cheers,
Chris
-- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist