I meant -- why use an extension and why do you need the aggregate() function?Weirdan wrote:Christopher:VladSun wrote: [...] in order to implement the aggregate() function.
Firing and handling events
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Firing and handling events
(#10850)
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Firing and handling events
What would be an application for an event system in PHP? This is new to me.
Re: Firing and handling events
Thanks, it did the trickWeirdan 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.
There are 10 types of people in this world, those who understand binary and those who don't
Re: Firing and handling events
It's not clear for me yetChristopher wrote:... why do you need the aggregate() function?
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
Re: Firing and handling events
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.Jonah Bron wrote:What would be an application for an event system in PHP? This is new to me.
There are 10 types of people in this world, those who understand binary and those who don't
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Firing and handling events
OKVladSun wrote:It's not clear for me yet![]()
Something like achieving runtime class inheritance (multiple)![]()
I was thinking of something much simpler (see my example)VladSun wrote:You said - "you may use composition vs. inheritance" and I respond with aggregation
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)
Re: Firing and handling events
It looks like a composition to me...Christopher wrote:I was thinking of something much simpler (see my example)VladSun wrote:You said - "you may use composition vs. inheritance" and I respond with aggregation
I can't get it. Can you elaborate, please.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?
There are 10 types of people in this world, those who understand binary and those who don't
Re: Firing and handling events
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.Jonah Bron wrote:What would be an application for an event system in PHP? This is new to me.
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
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Firing and handling events
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?
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
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.
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.
As mentioned above, it's especially useful for letting other developers extend the functionality of your code, without having to dig into the source.What would be an application for an event system in PHP? This is new to me.
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
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.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?
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
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Firing and handling events
In what way would it alter the data, and how would that be helpful?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
Ah, so you're saying that the system can listen to events fired by a plugin?VladSun wrote:An event may in turn fire another event which is processed by the "system" by performing some additional actions.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Firing and handling events
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:In what way would it alter the data, and how would that be helpful?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
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.Jonah Bron wrote:Ah, so you're saying that the system can listen to events fired by a plugin?VladSun wrote:An event may in turn fire another event which is processed by the "system" by performing some additional actions.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Firing and handling events
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.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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Firing and handling events
Not sure if you are asking or not, but...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.
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