[geeklog-devtalk] geeklog-devel digest, Vol 1 #361 - 7 msgs
geeklog-devel-request at lists.geeklog.net
geeklog-devel-request at lists.geeklog.net
Sun Aug 1 10:43:00 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: 1.3.10 to do list (Blaine Lang)
2. Re: 1.3.10 to do list (Dirk Haun)
3. How's the PDF generation supposed to work? (Dirk Haun)
4. Re: GL2 event model (Vincent Furia)
5. Re: Is this rocking the boat? (Vincent Furia)
6. Re: Is this rocking the boat? (Blaine Lang)
7. Re: GL2 event model (Blaine Lang)
--__--__--
Message: 1
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] 1.3.10 to do list
Date: Sat, 31 Jul 2004 15:30:55 -0400
Reply-To: geeklog-devel at lists.geeklog.net
Thanks for the feedback Dirk - all good points.
Item 1: The archivetopioc setting. No Problem I was just trying to not add
too many new fields.
- Adding a arhive flag is no issue.
- If I add a archivetopic field then we have to have another selectbox for
this in the editform.
Do we think users will need that extra flexibilty ?
Item2: My thinking was to make it a deliberate 2-step or 2-click process to
ensure the user was not enabling this by mistake. But have made the
suggested changed to the setting the options. Only concern is by enabling it
via the checkbox, the archive option is now also checked and the default
date is now. So - with one click if this is in error, the story will be
auto-archived upon saving.
Item3: Making this still work even with JS disabled. Well I had to think
about that one for a bit but have a nice solution (IMHO) and maybe we can
use this elseware. I added this logic to the bottom of the form and set the
template variable {showarchivedisabled} if the form area for this feature
and its controls should be disabled. Only if JS is enabled will this code
execute. I'm sure this could be enhanced or made more flexible as a
function.
<script>
<!-- This code will only be executed by a browser that suppports
Javascript -->
var jstest = {showarchivedisabled}
if (jstest) {
document.frmstory.expire_month.disabled=true;
.. and any other form fields
</script>
Let me know if there is a preference for Item1
I'll hold off submitting these changes until them as it will effect the
package.
Blaine
----- Original Message -----
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Saturday, July 31, 2004 4:57 AM
Subject: Re: [geeklog-devel] 1.3.10 to do list
Blaine,
>I have just submitted to CVS the changes to support the Story Archive
>Feature.
Nice work. A couple of comments:
I'm not happy with the $_CONF['archivetopic'] variable. Topic IDs should
be kept out of the config.php, IMO. I can think of 2 better ways to do this:
1) Add an "Archive" flag to the topics table, similar to the default
topic flag.
2) Even more flexible: Add the archive topic id to the story table, so
that stories can be archived in different topics.
I'm open to other ideas, but please keep the topic ID out of config.php.
The user interface for that option is a bit clumsy. First you have to
enable archiving and then you have to select whether you want Auto
Archive or Auto Delete. I would assume that Auto Archive is the option
you'll want in most cases, so could you make that one selected
automatically when enabling the option?
>I have used Javascript to disable the extra
>fields in the story editor "Edit" screen if this option is disabled. The
>default is for this option to be disabled unless toggled on per story. It's
>a nice touch but I may have to disable it or find a quick way to leave
these
>new fields enabled if JS is disabled in the browser. Just about everyone
has
>JS enabled don't they :)
Thanks to Mozilla's fine-grained Javascript options, I do have Javascript
enabled most of the time. But I do use Lynx on occasion ...
>This is a topic for another day but maybe we assume JS is enabled for
>Admin's and start to use JS to improve the UI.
>I'd love to see a nice Tab'ed interface for some of these large admin
pages.
I not opposed to using Javascript to make things easier / more
comfortable, but every option should also be available without Javascript.
bye, Dirk
--
http://www.haun-online.de/
http://geeklog.info/
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
--__--__--
Message: 2
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] 1.3.10 to do list
Date: Sat, 31 Jul 2004 22:06:55 +0200
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net
Blaine,
>- Adding a arhive flag is no issue.
>- If I add a archivetopic field then we have to have another selectbox for
>this in the editform.
>Do we think users will need that extra flexibilty ?
I'm fine with either option. What do the others think?
>So - with one click if this is in error, the story will be
>auto-archived upon saving.
I see your point now and have to agree. So better leave it as it was.
>Only if JS is enabled will this code execute.
Cool. Nice solution.
bye, Dirk
--
http://www.haun-online.de/
http://geeklog.info/
--__--__--
Message: 3
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Date: Sat, 31 Jul 2004 23:26:36 +0200
Organization: Terra Software Systems
Subject: [geeklog-devel] How's the PDF generation supposed to work?
Reply-To: geeklog-devel at lists.geeklog.net
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?
After setting
$_CONF['pdf_adhoc_enabled'] = 1;
the same thing (multiple creation of identical PDFs) happens for normal
users, too. Again: Why?
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
--
http://www.haun-online.de/
http://www.haun.info/
--__--__--
Message: 4
Date: Sat, 31 Jul 2004 23:11:51 -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
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
> >
> >
>
>
>
--__--__--
Message: 5
Date: Sat, 31 Jul 2004 23:17:17 -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 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
>
--__--__--
Message: 6
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Is this rocking the boat?
Date: Sun, 1 Aug 2004 10:33:02 -0400
Reply-To: geeklog-devel at lists.geeklog.net
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
--__--__--
Message: 7
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] GL2 event model
Date: Sun, 1 Aug 2004 10:42:38 -0400
Reply-To: geeklog-devel at lists.geeklog.net
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
End of geeklog-devel Digest
More information about the geeklog-devtalk
mailing list