[dokuwiki] Re: events


On Apr 18, 2006, at 6:39 AM, Chris Smith wrote:
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.

A wrapper for the trigger() method is simple. A wrapper for advise() would only work for events that take no (default) action....

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.

Are you saying that events that have side effects (but do not return results) should also use *_before and *_after events? In that case almost all events will use signal *_before and *_after, which is what I was advocating in the beginning.

Treating "DOKUWIKI_START" and "DOKUWIKI_END" as a pair, so something like "DOKUWIKI_RUN_BEFORE" and "DOKUWIKI_RUN_AFTER" are signaled instead is an interesting idea. I wonder if it would make any practical difference?

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.

I think this is a good approach. The location in the code could change causing an event name change. However forcing plugin authors to review their plugins (in this situation) would probably prevent unexpected plugin behavior caused by moving the event.

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.

I was thinking of putting the uppercasing in register_hook(), but keeping things case sensitive is ok. If the names are going to be uppercase then I think "_before" and "_after" should be uppercase also. This way plugin authors register for events like "DOKUWIKI_RUN_BEFORE" not "DOKUWIKI_RUN_before".

Regards, Ben Coburn


-------------------
   silicodon.net
-------------------

--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: