[dokuwiki] Re: events
- From: Chris Smith <chris@xxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Tue, 18 Apr 2006 14:39:53 +0100
Hi Ben,
I broadly agree with what you are saying, any differences I have are
pretty minor.
<event_name>_before v <event_name>, I would think one is as good as
another, documentation would cover any problems with either.
ignore_prevent_default, is an implementation v documentation thing. An
event can still be badly implemented and not behave as indicated by the
flag. However, that is clearer, if the documentation is out of step
with the code, it may not be clear which is right and which is wrong.
If the code is clearly behaving at odds with itself, its a bug.
Call back as part of the trigger makes sense. This also removes any
potential issue with event handlers modifying the function as it would
no longer need to be an event property.
I would like to get to a one statement event. I don't much like the idea
of requiring,
$evt = new event(...)
$evt->trigger(...) or $evt->advise(...)
maybe that would require a function wrapper. A function wrapper would
have the added advantage of including an unset($evt) as well.
I'd be grateful for any ideas from you or other list readers on this.
My only issue with always signalling an *_after advise is trying to keep
the system as light weight as possible. Signalling an after event when
there has been no action seems superfluous, but assuming yall handlers
have registered for the _before event means the addition of one function
call, one conditional check and one function return, which isn't onerous.
I think your example is disingenuous, as my point was the event had to
have no meaningful result or no meaningful effect. Deleting a page and
creating a page have meaningful effects. Signalling "DOKUWIKI_START"
has no action and therefore no meaningful effect so an _after advise has
no real meaning, excepting it comes after the _before advise. But then
maybe that in itself is meaningful enough, or maybe the event should be
constructed differently to pair it with DOKUWIKI_END and have it ignore
preventDefault.
Giving the classes and functions unique names is a good point.
I'd like to organise event names a little better too. Say the first
part of an event name would correspond to the part of dokuwiki which
signals it (e.g. based on the script file name). Events would change to
something like:
DOKU_DOKUWIKI_INITIALISED (DOKUWIKI_START)
DOKU_DOKUWIKI_ENDED (DOKUWIKI_END)
ACTION_ACT_PREPROCESS (ACTION_DISPATCH)
ACTION_ACT_UNRECOGNISED (ACTION_TEMPLATE)
TPL_ACT_RENDER (TPL_ACTION_HTML)
TPL_CONTENT_DISPLAY (TPL_ACTION_DISPLAY)
ACTION_HEADERS_SEND (HEADERS_SEND)
PARSER_HANDLER_FINALISED (HANDLER_FINALISED)
That would in general make the format
<reference to dokuwiki location>_<noun referring to data>_<verb
referring to event action or past tense of a particular state>. I guess
the reference to the dokuwiki location isn't necessary, but it could be
a handy convenience.
For me capital letters tend to imply constants in code. I'd prefer event
names to be case sensitive simply because it avoids some extra string
handling. But if consensus is one more str_toupper or str_tolower in
the event constructor is no problem (and I guess we are talking
miniscule numbers of microseconds), case insensitivity shouldn't be a
problem.
Even though, we now have a system we two are (mostly) happy with :-),
I'd rather not change anything for a short period of time to get some
opinions from others, including Andi.
Cheers,
Chris
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
