[geeklog-devel] GL2 event model
Blaine Lang
geeklog at langfamily.ca
Sun Aug 1 10:42:38 EDT 2004
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
More information about the geeklog-devel
mailing list