[geeklog-devtalk] geeklog-devel digest, Vol 1 #363 - 5 msgs
geeklog-devel-request at lists.geeklog.net
geeklog-devel-request at lists.geeklog.net
Mon Aug 2 12:11:01 EDT 2004
Send geeklog-devel mailing list submissions to
geeklog-devel at lists.geeklog.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
geeklog-devel-request at lists.geeklog.net
You can reach the person managing the list at
geeklog-devel-admin at lists.geeklog.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."
Today's Topics:
1. Re: How's the PDF generation supposed to work? (Tony Bibbs)
2. Re: Is this rocking the boat? (Tony Bibbs)
3. Re: GL2 event model (Tony Bibbs)
4. Re: Is this rocking the boat? (Vincent Furia)
5. Re: GL2 event model (Vincent Furia)
--__--__--
Message: 1
Date: Mon, 02 Aug 2004 09:02:11 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] How's the PDF generation supposed to work?
Reply-To: geeklog-devel at lists.geeklog.net
Dirk Haun wrote:
>Hmm, I thought the problems I had with the PDF generation where mostly
>due to the lack of a PDF plugin for MacOS X (yes, Simon, I know there's
>an unofficial one), but on closer inspection, that doesn't seem to be all ...
>
>So I have
>$_CONF['pdf_enabled'] = 1;
>$_CONF['pdf_adhoc_enabled'] = 0;
>
>Normal users get the PDF icon and when they click on it, they are being
>told that "The PDF feature has been disabled". So why is that icon there
>in the first place?
>
>For Admins, clicking on the PDF icon creates a new PDF file. Every time.
>So after 5 clicks, I have 5 identical PDFs (for the same story). Why?
>
>
It's a problem with the filename given to the PDF...which is currently
the current unixtimestamp instead of the SID. I'll get that fixed.
>After setting
>
>$_CONF['pdf_adhoc_enabled'] = 1;
>
>the same thing (multiple creation of identical PDFs) happens for normal
>users, too. Again: Why?
>
>
That setting should only enable the ad-hoc feature where you can enter
any external URL and generate the PDF.
>That I only get an empty browser window once pdfgenerator.php redirects
>to pdfgenerator.php?cmd=getPDF&pdfFile=20040731232336946.pdf may be due
>to local setup issues - still investigating that one.
>
>bye, Dirk
>
>
I'll look at this all sometime today.
--Tony
--__--__--
Message: 2
Date: Mon, 02 Aug 2004 09:13:03 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Is this rocking the boat?
Reply-To: geeklog-devel at lists.geeklog.net
Well, as far as other DB connections go, that is up to the coder,
obviously. GL2 should only worry about talking to the GL2 database so
if you want to access another database you should, without much hassle,
be able to open connections using the Creole DB layer that Propel uses:
http://creole.phpdb.org/wiki/
Obviously you can still do your own with PEAR::DB or raw MySQL in your
code. The DAO layer simply provides a slick way to prevent the
developer from issuing raw SQL in the code...sometimes that can't be
avoided and I'm sure there is probably way to issue raw SQL in unique
scenarios (I need to verify that).
--Tony
Blaine Lang wrote:
>It does look interesting and like many new libraries or models, it may be
>able to improve code readability, reduce code size, and improve
>re-useability but I do wonder if
> 1) There are any SQL usage restrictions or more complex SQL queries that
>will not work.
> 2) Will you still be able to use another DB access method and direct mysql_
>calls using PHP
> 3) Making GL2 too complex to understand for developers will effect it's
>support
>
>I have had reason on several occasions to need to access another mysql
>database when doing application integration. I just used the direct php
>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x
>does not support this. We should consider this need in GL2
>
>Blaine
>----- Original Message -----
>From: "Vincent Furia" <vfuria at gmail.com>
>To: <geeklog-devel at lists.geeklog.net>
>Sent: Saturday, July 31, 2004 11:17 PM
>Subject: Re: [geeklog-devel] Is this rocking the boat?
>
>
>I haven't had enough time to read up on this extensively, but it looks
>promising. We just have to make sure that it fulfills all our needs
>completely and won't cause any problems down the road. Also, we have
>to be able to support it on the off chance that the current developers
>drop the project.
>
>My one worry is possible performance penalties. I think we should
>check how much overhead Propel requires.
>
>Most importantly: I want to see GL2 get moving really soon. So a
>decision on this has to happen soon. Can we get enough research done
>on this topic that we're not causing more delays?
>
>I'll spend some more time reading the Propel docs. If nothing else the
>idea sounds pretty interesting.
>
>-Vinny
>
>On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
>
>
>>Ok, I think I sent this link here, but the more I read what I see, the
>>more I like it. Please take some time to read about Propel:
>>
>>http://propel.phpdb.org
>>
>>And read the user guide:
>>
>>http://propel.phpdb.org/docs/user_guide/
>>
>>The long and short of it is this. We could implement Data Acces Objects
>>that our code uses to interact with the database. DAO is a good idea no
>>matter what DB abstraction layer we use and regardless if we use a tool
>>like Propel. Essentially it hides the data access specifics from the
>>developers. Instead developers will call simple methods on the data
>>access objects and let the DAO layer do the grunt work.
>>
>>We could essentially use DAO to wrap the use of Propel for data acess.
>>
>>That said there are some pros and cons:
>>
>>Pros:
>>1) Clean API, developers no longer have to write SQL except in really
>>rare instances.
>>2) Object oriented...right in line with GL2
>>3) Database changes are easier, now developers don't have to find all
>>SQL effected by a database change. We simply change things at the
>>Propel level (wrapped by DAO), modify our HTML templates and we are off
>>to the race.
>>
>>Cons:
>>1) It is conceptionally more complicated. Requires some ramp up.
>>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even
>>if you wanted to).
>>3) It's in Beta.
>>
>>I think this tool could really save a ton of time. Please give this a
>>gander and try using it against a very simply table and let me know your
>>thoughts.
>>
>>--Tony
>>_______________________________________________
>>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
>
>
--__--__--
Message: 3
Date: Mon, 02 Aug 2004 09:21:43 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 event model
Reply-To: geeklog-devel at lists.geeklog.net
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
>
>
--__--__--
Message: 4
Date: Mon, 2 Aug 2004 12:01:03 -0400
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Is this rocking the boat?
Reply-To: geeklog-devel at lists.geeklog.net
I just noticed this about propel (pre-installation requirements):
# PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable
php_xsl.dll on Windows)
Is XSLT a commonly supported item? Can we depend on it being compiled
in on most PHP5 installations at ISPs?
-Vinny
On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> Well, as far as other DB connections go, that is up to the coder,
> obviously. GL2 should only worry about talking to the GL2 database so
> if you want to access another database you should, without much hassle,
> be able to open connections using the Creole DB layer that Propel uses:
>
> http://creole.phpdb.org/wiki/
>
> Obviously you can still do your own with PEAR::DB or raw MySQL in your
> code. The DAO layer simply provides a slick way to prevent the
> developer from issuing raw SQL in the code...sometimes that can't be
> avoided and I'm sure there is probably way to issue raw SQL in unique
> scenarios (I need to verify that).
>
> --Tony
>
>
>
> Blaine Lang wrote:
>
> >It does look interesting and like many new libraries or models, it may be
> >able to improve code readability, reduce code size, and improve
> >re-useability but I do wonder if
> > 1) There are any SQL usage restrictions or more complex SQL queries that
> >will not work.
> > 2) Will you still be able to use another DB access method and direct mysql_
> >calls using PHP
> > 3) Making GL2 too complex to understand for developers will effect it's
> >support
> >
> >I have had reason on several occasions to need to access another mysql
> >database when doing application integration. I just used the direct php
> >mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x
> >does not support this. We should consider this need in GL2
> >
> >Blaine
> >----- Original Message -----
> >From: "Vincent Furia" <vfuria at gmail.com>
> >To: <geeklog-devel at lists.geeklog.net>
> >Sent: Saturday, July 31, 2004 11:17 PM
> >Subject: Re: [geeklog-devel] Is this rocking the boat?
> >
> >
> >I haven't had enough time to read up on this extensively, but it looks
> >promising. We just have to make sure that it fulfills all our needs
> >completely and won't cause any problems down the road. Also, we have
> >to be able to support it on the off chance that the current developers
> >drop the project.
> >
> >My one worry is possible performance penalties. I think we should
> >check how much overhead Propel requires.
> >
> >Most importantly: I want to see GL2 get moving really soon. So a
> >decision on this has to happen soon. Can we get enough research done
> >on this topic that we're not causing more delays?
> >
> >I'll spend some more time reading the Propel docs. If nothing else the
> >idea sounds pretty interesting.
> >
> >-Vinny
> >
> >On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> >
> >
> >>Ok, I think I sent this link here, but the more I read what I see, the
> >>more I like it. Please take some time to read about Propel:
> >>
> >>http://propel.phpdb.org
> >>
> >>And read the user guide:
> >>
> >>http://propel.phpdb.org/docs/user_guide/
> >>
> >>The long and short of it is this. We could implement Data Acces Objects
> >>that our code uses to interact with the database. DAO is a good idea no
> >>matter what DB abstraction layer we use and regardless if we use a tool
> >>like Propel. Essentially it hides the data access specifics from the
> >>developers. Instead developers will call simple methods on the data
> >>access objects and let the DAO layer do the grunt work.
> >>
> >>We could essentially use DAO to wrap the use of Propel for data acess.
> >>
> >>That said there are some pros and cons:
> >>
> >>Pros:
> >>1) Clean API, developers no longer have to write SQL except in really
> >>rare instances.
> >>2) Object oriented...right in line with GL2
> >>3) Database changes are easier, now developers don't have to find all
> >>SQL effected by a database change. We simply change things at the
> >>Propel level (wrapped by DAO), modify our HTML templates and we are off
> >>to the race.
> >>
> >>Cons:
> >>1) It is conceptionally more complicated. Requires some ramp up.
> >>2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even
> >>if you wanted to).
> >>3) It's in Beta.
> >>
> >>I think this tool could really save a ton of time. Please give this a
> >>gander and try using it against a very simply table and let me know your
> >>thoughts.
> >>
> >>--Tony
> >>_______________________________________________
> >>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
>
--__--__--
Message: 5
Date: Mon, 2 Aug 2004 12:10:48 -0400
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 event model
Reply-To: geeklog-devel at lists.geeklog.net
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
>
--__--__--
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
End of geeklog-devel Digest
More information about the geeklog-devtalk
mailing list