[geeklog-devel] GL2 event model
Vincent Furia
vfuria at gmail.com
Mon Aug 2 12:10:48 EDT 2004
I think the "Level" idea is overkill, and something that is not really
needed. When a developer add events to a plugin (or a the core) they
should be well documented. Included in that documentation is whether
event listeners should be able to take over execution (not return a
value, or return something indicating they completed successfully) or
if they can cause different types of errors to occur (up to fatal
presumably) for that specific event. (This would be something our
"approved plugin" review should be taking a look at.)
Adding the "Levels" I think would begin to make things too complicated
and could cause problems when it comes to plugin interaction. I think
the "priority" field will be sufficient without adding complexity from
the developers perspective.
If I misunderstood, and these "Levels" don't represent a separate
field but a way to organize the "priority" numbers, I can think of
many instances where you might want passive plugins to occur before or
after non-passive plugins. Forcing ordering based on action type
seems like a bad idea.
I hope I haven't misunderstood what you meant...
-Vinny
On Mon, 02 Aug 2004 09:21:43 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> Getting back to my suggestion about having a standard set of plugins
> this is what i was eluding too.
>
> Level 10 may indicate that the plugin takes passive action. In
> otherwords, it will do something internally and not stop program
> execution. This would be transparent to the user.
> Level 20 may indicate the plugin may take some sort of action not
> tranparent to the user and the plugin will not stop program execution.
> Level XX indicates the plugin may fatally abort the event call and stop
> execution.
>
> Not sure if this makes sense or not. Obviously we would drive the
> levels by constants so we could tweak this. That make any sense?
>
> --Tony
>
>
>
> Blaine Lang wrote:
>
> >I like this idea of a priority field for the event model. As Vinny noted, a
> >2nd level of privilege for core functions is also needed. We have the issue
> >now in GL1.3 where we scan the plugins to see if functions are present and
> >it's in order of installation. So if 3 plugins have a centerblock, you have
> >no way of changing the order.
> >
> >I don't know if thats a good example of usage for this field - I don't think
> >it is so there may be another field used to control this.
> >
> >Do we need to have classes of plugins or modules as well.
> > - Core
> > - Service Providers (Messenging, Formatting)
> > - Interface Related
> > - Misc
> >
> >Just wondering if this classification would be useful.
> >
> >Blaine
> >----- Original Message -----
> >From: "Vincent Furia" <vfuria at gmail.com>
> >To: <geeklog-devel at lists.geeklog.net>
> >Sent: Saturday, July 31, 2004 11:11 PM
> >Subject: Re: [geeklog-devel] GL2 event model
> >
> >
> >No problem with the addition that Tony made. I also agree that we
> >should add a 'precedence' (what Tony call priority) field. I think
> >this is as easy as changing one function in the class:
> >
> >public function registerListener($events, $plugin)
> >--to--
> >public function registerListener($events, $plugin, $precedence = 100)
> >
> >And when the $listeners field is loaded, the array of events should be
> >populate in order lower precedence to higher precedence.
> >
> >Where $precedence is an integer that we recommend goes from 0 - 255.
> >The Geeklog core then could potentially use precedence values > 255 or
> >< 0 if it needs to operate before or after all the other plugins.
> >Really, I don't think it matters what numbers we use, so any
> >suggestions that are more logical from a plugin developers standpoint
> >would be great.
> >
> >-Vinny
> >
> >On Fri, 30 Jul 2004 15:50:35 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> >
> >
> >>To fill in the blanks more I offer up the attached version. Only
> >>difference is I show how the plugins are actually called. Also, we
> >>might want to consider a 'priority' field for events that plugins listen
> >>to. Using priorities would allow plugins to get called in some sort of
> >>priorty fashion. I say that we come up with a standard set of
> >>priorities that plugins can use. This make sense?
> >>
> >>--Tony
> >>
> >>
> >>
> >>Vincent Furia wrote:
> >>
> >>
> >>
> >>>Here is what I had envisioned when I penned the Plugin API
> >>>documentation. It is a class that would be instantiated only once by
> >>>GL2 core and available globally. I prefer the per event registration
> >>>as it will reduce the calls the "PluginEventHanlder" will have to make
> >>>to listening plugins.
> >>>
> >>>-Vinny
> >>>
> >>>class PluginEventHandler {
> >>>
> >>> /**
> >>> * Array containing event keys and listener (arrays as) values
> >>> * @access private
> >>> * @var array
> >>> */
> >>> private $listeners = array();
> >>>
> >>> /**
> >>> * PluginEventHandler Constructor
> >>> *
> >>> * @access public
> >>> *
> >>> */
> >>> function __construct() {
> >>> // fetch registered listeners from database, populate $listeners
> >>> }
> >>>
> >>> /**
> >>> * Register a plugin to listen for an event
> >>> *
> >>> * @access public
> >>> * @param mixed $event event(s) to listen for (string or array)
> >>> * @param string $plugin plugin to be registered as listener
> >>> * @return boolean true on success
> >>> *
> >>> */
> >>> function registerListener($event, $plugin) {
> >>> // add the listener to the $listeners variable and the database
> >>> }
> >>>
> >>> /**
> >>> * Unregister a plugin from listening for an event
> >>> *
> >>> * @access public
> >>> * @param mixed $event event(s) to unregister (string or array)
> >>> * @param string $plugin plugin to be unregistered as listener
> >>> * @return boolean true on success
> >>> *
> >>> */
> >>> function unregisterListener($event, $plugin) {
> >>> // remove the listener for the specified events from $listeners
> >>> // and the database.
> >>> }
> >>>
> >>> /**
> >>> * Get all the listeners for a specific event
> >>> *
> >>> * @access public
> >>> * @param string $event event to get listeners of
> >>> * @return array array of listeners to event $event
> >>> *
> >>> */
> >>> function getListeners($event) {
> >>> // remove the listener for the specified events from $listeners
> >>> // and the database.
> >>> }
> >>>
> >>> /**
> >>> * Notify all listeners that an event has occurred
> >>> *
> >>> * @access public
> >>> * @param mixed $event event requiring notification
> >>> * @param mixed $vars event specific variables
> >>> * @param mixed $plugin NOTIFY_ALL, specific plugin, or array of
> >>>
> >>>
> >plugins
> >
> >
> >>> * @return mixed event specific return values (or array of)
> >>> *
> >>> */
> >>> function notify($event, $vars, $plugin = NOTIFY_ALL) {
> >>>
> >>> }
> >>>
> >>>}
> >>>
> >>>
> >>>
> >>>On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett <tomw at pigstye.net> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Let me get this straight.
> >>>>
> >>>>GL2 Core would make the MySubjectObserverClass
> >>>>
> >>>>$obs = new MySubjectObserverClass;
> >>>>
> >>>>then the plugin would register by somehow getting the reference to the
> >>>>MySubjectOvserverClass and register itself as a listener
> >>>>
> >>>>$obs->addListner($MyPlugin);
> >>>>or
> >>>>$obs->addListener($MyPlugin, $events);
> >>>>etc
> >>>>
> >>>>Then when a event happened GL2 Core or a plugin could notify the plugins
> >>>>
> >>>>$obs->notifyAll($event)
> >>>>
> >>>>Do I have this about right?
> >>>>
> >>>>--
> >>>>Tom Willett
> >>>>tomw at pigstye.net
> >>>>
> >>>>
> >>>>
> >>>>---------- Original Message -----------
> >>>>From: Tony Bibbs <tony at tonybibbs.com>
> >>>>To: geeklog-devel at lists.geeklog.net
> >>>>Sent: Wed, 21 Jul 2004 16:31:57 -0500
> >>>>Subject: [geeklog-devel] GL2 event model
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>The plugin API for GL2 that Vinny has drafted if surprisingly small
> >>>>>because we are introducing an event based model. Essentially, the GL2
> >>>>>and all plugins have the option to register events that others can
> >>>>>listen to. To implement this I recommend an observer/observable design
> >>>>>pattern similar to the example below. A few things that need
> >>>>>discussion. First, the example below allows listening only at the
> >>>>>object level. The alternative is the force listening at the event
> >>>>>
> >>>>>
> >level
> >
> >
> >>>>>(in otherwords, addListener would take as a second arg an array of
> >>>>>events the object listens to). Any preference? General questions?:
> >>>>>
> >>>>>class MySubjectObserverClass {
> >>>>> private $listeners = array();
> >>>>> private $listernerNextID = 0;
> >>>>>
> >>>>> // Alternative names: register, subscribe...
> >>>>> public function addListerner(&$obj)
> >>>>> {
> >>>>> $this->_listerners[] =& $obj;
> >>>>> return $this->listernerNextID++;
> >>>>> }
> >>>>>
> >>>>> // Alternative name: unregister, unsubscribe...
> >>>>> public function removeListerner($id,'even't)
> >>>>> {
> >>>>> unset($this->listerners[$id]);
> >>>>> }
> >>>>>
> >>>>> // Alternative name: broadcast...
> >>>>> public function notifyAll($event)
> >>>>> {
> >>>>> foreach ($this->listerners as $id => $obj)
> >>>>> {
> >>>>> $this->listerners[$id]->notify($event, $this);
> >>>>> }
> >>>>> }
> >>>>>
> >>>>> // Alternative name: listen...
> >>>>> function notify($event, &$obj)
> >>>>> {
> >>>>> switch (get_class($obj)) {
> >>>>> case 'blah':
> >>>>> ...
> >>>>> }
> >>>>> }
> >>>>>}
> >>>>>
> >>>>>_______________________________________________
> >>>>>geeklog-devel mailing list
> >>>>>geeklog-devel at lists.geeklog.net
> >>>>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>------- End of Original Message -------
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>geeklog-devel mailing list
> >>>>geeklog-devel at lists.geeklog.net
> >>>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________
> >>>geeklog-devel mailing list
> >>>geeklog-devel at lists.geeklog.net
> >>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >_______________________________________________
> >geeklog-devel mailing list
> >geeklog-devel at lists.geeklog.net
> >http://lists.geeklog.net/listinfo/geeklog-devel
> >
> >_______________________________________________
> >geeklog-devel mailing list
> >geeklog-devel at lists.geeklog.net
> >http://lists.geeklog.net/listinfo/geeklog-devel
> >
> >
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
More information about the geeklog-devel
mailing list