Page 2 of 3

Re: Firing and handling events

Posted: Tue Oct 05, 2010 10:35 pm
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?

Re: Firing and handling events

Posted: Tue Oct 05, 2010 11:05 pm
by Jonah Bron
What would be an application for an event system in PHP? This is new to me.

Re: Firing and handling events

Posted: Wed Oct 06, 2010 2:37 am
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 :)

Re: Firing and handling events

Posted: Wed Oct 06, 2010 2:42 am
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 :)

Re: Firing and handling events

Posted: Wed Oct 06, 2010 2:47 am
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.

Re: Firing and handling events

Posted: Wed Oct 06, 2010 3:16 am
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?

Re: Firing and handling events

Posted: Wed Oct 06, 2010 3:33 am
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.

Re: Firing and handling events

Posted: Wed Oct 06, 2010 7:22 am
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

Re: Firing and handling events

Posted: Wed Oct 06, 2010 10:43 am
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?

Re: Firing and handling events

Posted: Wed Oct 06, 2010 12:12 pm
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.

Re: Firing and handling events

Posted: Wed Oct 06, 2010 4:26 pm
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 :)

Re: Firing and handling events

Posted: Wed Oct 06, 2010 7:45 pm
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?

Re: Firing and handling events

Posted: Wed Oct 06, 2010 9:07 pm
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.

Re: Firing and handling events

Posted: Thu Oct 07, 2010 11:55 am
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.

Re: Firing and handling events

Posted: Thu Oct 07, 2010 12:02 pm
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