[dokuwiki] Re: events
- From: Ben Coburn <btcoburn@xxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sat, 15 Apr 2006 18:07:54 -0700
On Apr 15, 2006, at 9:55 AM, Chris Smith wrote:
I am not particularly happy with retrofitting events like I have done,
or the nomenclature used so would welcome suggestions on both.
That should be enough events from me for a while and enough to kick
start the system. I'll copy the patch notes to splitbrain to provide
the start of an events list (unless someone else get there before
me... ;-) )
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.
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.
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...
/*
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.
I started this email as a "thinking out load" review of the code,
however I believe points 1 and 3 are important enough that I will write
up a darcs patch for them as I have time.
Regards, Ben Coburn
-------------------
silicodon.net
-------------------
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
