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
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 »

Weirdan wrote:Christopher:
VladSun wrote: [...] in order to implement the aggregate() function.
I meant -- why use an extension and why do you need the aggregate() function?
(#10850)
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 »

What would be an application for an event system in PHP? This is new to me.
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 »

Weirdan wrote:Vlad, there's a fork of runkit (that is actually being developed) available on github, with support for php 5.3. pecl install http://github.com/downloads/zenovich/ru ... -1.0.2.tgz should do the trick.

Christopher:
VladSun wrote: [...] in order to implement the aggregate() function.
Thanks, it did the trick :)
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 »

Christopher wrote:... why do you need the aggregate() function?
It's not clear for me yet :lol:
Something like achieving runtime class inheritance (multiple) :)

You said - "you may use composition vs. inheritance" and I respond with aggregation :)
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 »

Jonah Bron wrote:What would be an application for an event system in PHP? This is new to me.
I use this approach in order to have a fully pluggable modular system. Also, I like the idea of using events to intercept with method flows instead of explicitly overriding these methods.
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:It's not clear for me yet :lol:
Something like achieving runtime class inheritance (multiple) :)
OK :)
VladSun wrote:You said - "you may use composition vs. inheritance" and I respond with aggregation :)
I was thinking of something much simpler (see my example)

Have you also thought of inverting the process so instead in putting the fireEvent() calls between function calls -- you could register functions calls associated with events?
(#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 »

Christopher wrote:
VladSun wrote:You said - "you may use composition vs. inheritance" and I respond with aggregation :)
I was thinking of something much simpler (see my example)
It looks like a composition to me...
Christopher wrote:Have you also thought of inverting the process so instead in putting the fireEvent() calls between function calls -- you could register functions calls associated with events?
I can't get it. Can you elaborate, please.
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:What would be an application for an event system in PHP? This is new to me.
If you want people to be able to write "plugins" for your system. Or if you wanted to obfuscate your own code. (It makes the software more flexible but also more complex basically). It reverses dependencies.

For example, When you shut down your computer, it sends a "hangup" signal to all running programs. That hangup signal is like an event and those program listen & respond by prompting the user to save their data, shutting down, etc.. This way the operating system can "make" every program exit even though the operating system has knowledge of those programs.

See observer - subject: http://msdn.microsoft.com/en-us/library/ee817669.aspx
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 makes sense (I think). So, say you load some text file while the program is running, and you can setup an event called "beforeLoadFile" and maybe another called "afterLoadFile" so that a plugin can be fired when that happens. Is that a realistic example?

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?
mkz
Forum Newbie
Posts: 11
Joined: Tue Oct 05, 2010 10:37 am

Re: Firing and handling events

Post by mkz »

The Symfony project provides a stand-alone event handling class. It's pretty simple and succint, perhaps you can draw inspiration from it. It's called the Symfony Event Dispatcher.
What would be an application for an event system in PHP? This is new to me.
As mentioned above, it's especially useful for letting other developers extend the functionality of your code, without having to dig into the source.

Drupal, for example, makes very heavy use of events (although they call them "hooks"). This enables developers to create modules that can be added to Drupal, without needing to touch the core files. The result? Drupal has an entire microcosm of thousands of third-party modules, which are able to leverage the power of the Drupal core and add their own features.

edit to add: Exactly, that's actually a very realistic example. In web applications, you might also have events pertaining to the request being handled. So you might see "afterRequest" or "onFormGenerate" or something.

The beauty of it is that your plugin can use the event handling mechanism to fire events that it defines on its own, so that other plugins can take advantage of 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 »

Jonah Bron wrote:That makes sense (I think). So, say you load some text file while the program is running, and you can setup an event called "beforeLoadFile" and maybe another called "afterLoadFile" so that a plugin can be fired when that happens. Is that a realistic example?

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?
So, so. The plugin is loaded into the "system" and *listens* for specific events. If an event is received, the plugin performs some actions and may alter the data passed in the Event, so it may change the way the "system" process this data. An event may in turn fire another event which is processed by the "system" by performing some additional actions.

I intentionally put system in quotes so it's easy to be distinguished :)
There are 10 types of people in this world, those who understand binary and those who don't
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 »

VladSun wrote: If an event is received, the plugin performs some actions and may alter the data passed in the Event, so it may change the way the "system" process this data
In what way would it alter the data, and how would that be helpful?
VladSun wrote:An event may in turn fire another event which is processed by the "system" by performing some additional actions.
Ah, so you're saying that the system can listen to events fired by a plugin?
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Re: Firing and handling events

Post by John Cartwright »

Jonah Bron wrote:
VladSun wrote: If an event is received, the plugin performs some actions and may alter the data passed in the Event, so it may change the way the "system" process this data
In what way would it alter the data, and how would that be helpful?
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.
Jonah Bron wrote:
VladSun wrote:An event may in turn fire another event which is processed by the "system" by performing some additional actions.
Ah, so you're saying that the system can listen to events fired by a plugin?
No. The plugins listen for the events. Plugins may, or may not, also request additional events to be fired, however, it is usually the core system that fires the events that the plugins can attach themselves to.
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 »

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.
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 »

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.
Not sure if you are asking or not, but...

Server-side events are (should be/can be) unlimited per HTTP request. onMessageSubmit() might fire and be intercepted by 100 listeners, which in turn fire more events, etc.

It can lead to more difficult to follow code because of this hidden indirection in code execution. It's a price you pay for greater extensibility and reuse of existing components.

Cheers,
Alex
Post Reply