Firing and handling events

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Firing and handling events

Post by Jonah Bron »

I see. Before, I thought that there were events being fired for different parts of the application as it progressed. Like:

[syntax]receive request
fire event
load some file
fire event
query database
fire event
setup response
fire event
respond
fire event[/syntax]

But it sounds more like:

[syntax]receive specific request
fire event
all listeners fire
listeners fire more events
etc...[/syntax]

Right? Sorry I'm having so much trouble with this :roll:
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Firing and handling events

Post by alex.barylski »

Well it doesn't have to be structured, but I suppose it could be. Think of it this way.

Any method called can *fire* an event before or after it's own execution. This event can then be observed/listened too by any number of other methods/components/etc. Effectively hooking into that method and performing custom operations and possibly firing their own events for others to observe, but not strictly required.

Many events can fire in a system and none of them be observed, or all of them be observed/handled. That is what lends it self nicely to a truly pluggable/extendable system. There is really no order to the chaos, at least not in terms of listening. Some event systems might implement a priority technique to gaurantee listener A gets to handle the request before listener B, however this goes against the whole concept of truly pluggable system. If one listener requires another (is dependent upon) listener to handle the event first you make the code more fragile.

Cheers,
Alex
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Firing and handling events

Post by Jonah Bron »

Awesome, got it.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Firing and handling events

Post by VladSun »

Another thing to mention: my Event based system requires that every object has to declare its own events. So when a Listener declare a specific object event to listen on it's checked against the set of the events declared by this object. If no match has been found an Exception is thrown, so the client (Listener) knows it listens to an "invalid" event.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Firing and handling events

Post by VladSun »

PCSpectra wrote:... There is really no order to the chaos, at least not in terms of listening. Some event systems might implement a priority technique to gaurantee listener A gets to handle the request before listener B, however this goes against the whole concept of truly pluggable system ...
That's a thing I'm going to implement :)
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Firing and handling events

Post by Christopher »

VladSun wrote:Another thing to mention: my Event based system requires that every object has to declare its own events. So when a Listener declare a specific object event to listen on it's checked against the set of the events declared by this object. If no match has been found an Exception is thrown, so the client (Listener) knows it listens to an "invalid" event.
I think that can be good and bad. One thing about your code is that there are lots of declared events that are never implemented or share implementation. Having a looser way declare events might be nice. That is the way that Symfony Event Dispatcher implements it (and I assume the Apple Cocoa notification center).
(#10850)
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Firing and handling events

Post by VladSun »

I did this check after I had made some spelling mistakes in the event names. It's hard to debug otherwise.
There are 10 types of people in this world, those who understand binary and those who don't
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Firing and handling events

Post by josh »

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:

Code: Select all

  $('#myButton').click();
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.
User avatar
Jonah Bron
DevNet Master
Posts: 2764
Joined: Thu Mar 15, 2007 6:28 pm
Location: Redding, California

Re: Firing and handling events

Post by Jonah Bron »

That's really neat... you really cleared it all up for me, thanks a lot. :)
Post Reply