[dokuwiki] Re: the event system

Chris Smith wrote:
@Jason, if you haven't already, please check back in the archives for our original discussions on events. Quite a bit of what you say was covered there.
Thanks for the pointer. I didn't realize the huge amount of discussion that went on last April. I suppose it should have been obvious to me from the great design that exists now that a lot of thought and discussion went into it.
@Ben, My original system did have three callbacks. That was reduced to two when there wasn't seen any real difference between BEFORE and the event itself. I think we've now found that difference :-)
@all, I don't think it would be difficult to add a new advisement. Practically, its the same as BEFORE. The difference is in its recommended use. All existing plugins would continue to work unchanged. In time their authors would decide whether or not their use of the original BEFORE callback should take place during the data preparation phase or during the action phase.
Because the order between BEFORE events is not guaranteed, I think there is a nontrivial difference between BEFORE events and the primary callback--it's not just a difference in labeling. One place (maybe the only place) the difference comes up when I want to replace the default action of the event. If I have one plugin that wants to prepare data, but another plugin that acts on the data and replaces the default action, I can't guarantee that the preparer plugin gets run before the action. In an (admittedly contrived) example, suppose I have one plugin that performs redirects---it's always modifying the $id attribute of events so that the default action is always acting on a different page than what was originally set. If I implement my replacement action as a BEFORE callback, then I have no way of guaranteeing that the redirect plugin can do it's job before I do my action.
I do agree that adding the new advise (or maybe I should say the original third advise) would not break existing functionality. It would just provide more guarantees about when a callback is run.
@Jason. I don't think there is any need to add a "stop further advisements" facility. Can you give an example of where it could be useful? 

There are two reasons I added that:
1. To my understanding, that is what the stopPropagation() function already does. I was carrying forward (what I thought was) an already-existing feature. Why a BEFORE callback would prevent other BEFORE callbacks from being processed is debatable, though, especially if the order in which the callbacks are processed is not known.
2. stopPropagation() called in a primary callback (the new advisement) is something like the preventDefault(), just relabeled to be consistent with the idea that no other callbacks in the primary callback list will be called. 

Two comments:
1. the stopPropagation function doesn't seem to make much sense when there is no control over the order in which the callbacks are processed. As far as I can tell, it seems like the most likely uses of the stopPropagation function are when you are saying either "I want to be the only plugin to handle this, and I just hope that I'm the first one called" or "I know absolutely that no other plugin has any interest in handling this, so I'm going to just stop processing right now to save time." Either of these statements doesn't make much sense. You can't guarantee that you are the only one to handle a situation (that's the whole point of the event system---to let people have access to things), and you have no way of knowing that there will never be a plugin interested in processing things after you are done processing your bit. 

2. As far as I can see, the preventDefault function has two uses:
(a) you are replacing the default action, so you don't want the default action clobbering what you're doing. (b) you have some reason to want _nothing_ done---the default or any other replacements for the default shouldn't happen.
In (a), with the proposed addition of a third "primary callback" advise, you would implement your callback as a primary callback and then use stopPropagation.
In (b), if you called preventDefault from a BEFORE callback, then that had better also prevent _any_ primary callbacks from being called, not just the default one.
I might have missed some things in the above comments. Please feel free to correct me. 

Thanks,

Jason

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

Other related posts: