Jonah Bron wrote:I think I understand what you mean by "reverses dependencies". Instead of your base code calling the plugin, the plugin sort of "inserts" itself into the base code through the event system. Is that right?
Right. It "inserts" itself into the call stack at whatever point that event was fired via the observer pattern (so technically it doesn't insert itself but you can think about it that way because thats the job were actually accomplishing).
Jonah Bron wrote:John Cartwright wrote:Lets use this forum as an example. Perhaps we have an event onMessageSubmit().. being when we submit a post to a thread. Now, we could implement a BB parser plugin which would take the existing data the system passes through, and alters it to create the smilies, code tags, etc.
Oh, so I didn't quite understand. By the nature of your example event, it sounds like you're saying that it's basically one event per HTTP request.
No. For example you might have an event beforeModelSave & a plugin called "last modified time plugin" that update's a model's 'last updated' field each time it gets saved. If you saved 100 models that would be 100 events right there, all on one page.
Events are commonly used in the controller layer. An event called beforeDispatch would fire, a plugin would intercept execution and check user's credentials (from within a plugin). It would then decide to allow execution to continue or it would redirect them to the login screen, for example. This plugin gets "attached" to all controllers, so you get that duplicated auth code out of the controllers and centralized into a plugin. You could do the same thing with inheritance, but plug ins allow you to mimic multiple inheritance in a more organized way. You can cherry pick plugins on a controller by controller basis. Whereas with inheritance its all or nothing.
Another example is using it within your model layer, so that other programmers can write plugins for the business logic of the application.
A better example is the DOM. When you mouse over, mouse out, click, etc.. on any DOM element an event gets fired. A piece of javascript can "listen" for events on one button. The user must click on the button that that plugin is listening to, not just any button would do (unless that javascript were listening to all button clicks, or all clicks at the page level). You see the DOM's event system has "event bubbling". If you click a button it also counts as a click to that button's parent div, all parent tags of that button.
Code: Select all
$('#myButton').click( function() {
alert( 'ello governer');
});
What this piece of jquery says, is find all elements with an id of #myButton, and listen for click events. When a click event is fired, run this function..
Some one doesn't even need to click the button, they can just fire the event programmatically:
You could have multiple callback functions for a click event:
Code: Select all
$('#myButton').click( function() {
alert( 'ello governer');
});
$('button').click( function() {
alert( 'a second callback');
});
^ both of these functions are said to be "callbacks" for the click event.
Another example would be a database adapter that fires beforeQuery and afterQuery. A profiler plugin could be written for this class that start & stop a clock upon those events.
As flexible as events are, they are extra complexity and that complexity should be warranted if you're going to complicate your system with them.