[geeklog-devtalk] geeklog-devel digest, Vol 1 #355 - 6 msgs

[geeklog-devel-request at lists.geeklog.net]

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: Translation stuff for GL2 (Sean M. Cunningham)
   2. GL2 event model (Tony Bibbs)
   3. Re: GL2 event model (Tom Willett)
   4. Re: GL2 event model (Vincent Furia)
   5. Re: Re: Translation stuff for GL2 (Vincent Furia)
   6. Re: Re: Translation stuff for GL2 (Tony Bibbs)

--__--__--

Message: 1
Date: Wed, 21 Jul 2004 11:56:04 -0600
From: "Sean M. Cunningham" <seanmcunningham at comcast.net>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Re: Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

Hi All,
I was thinking that it might be kind of nice to have the translations 
incorporated with the themes. XSilver_en, XSilver_fr, XSilver_sp, and so 
on. Designing in my native language seems only natural and I would 
imagine that most designers are designing in their native languages 
also. A site that requires multiple languages would have to have the 
translator and designer working together though.
I feel that this could streamline the base code and simplify the themes, 
although it would increase the quantity of themes.
The trade off would be ok for me. What do you think?

-Sean


--__--__--

Message: 2
Date: Wed, 21 Jul 2004 16:31:57 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] GL2 event model
Reply-To: geeklog-devel at lists.geeklog.net

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':
               ...
       }
   }
}


--__--__--

Message: 3
From: "Tom Willett" <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 event model
Date: Wed, 21 Jul 2004 22:10:55 +0000
Reply-To: geeklog-devel at lists.geeklog.net

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 -------


--__--__--

Message: 4
Date: Wed, 21 Jul 2004 21:23: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

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

>


--__--__--

Message: 5
Date: Wed, 21 Jul 2004 21:36:38 -0400
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

The big down side to this method is that every theme will have to be
translated into every desired language.  So if a site wants 7 themes
(as comes with geeklog today) and 36 languages (as comes with geeklog
today) under this scheme they'd have to translate each theme 36 times.
 That's 252 themes and a whole lot of extra work for translators.

-Vinny

On Wed, 21 Jul 2004 11:56:04 -0600, Sean M. Cunningham
<seanmcunningham at comcast.net> wrote:

> Hi All,

> I was thinking that it might be kind of nice to have the translations

> incorporated with the themes. XSilver_en, XSilver_fr, XSilver_sp, and so

> on. Designing in my native language seems only natural and I would

> imagine that most designers are designing in their native languages

> also. A site that requires multiple languages would have to have the

> translator and designer working together though.

> I feel that this could streamline the base code and simplify the themes,

> although it would increase the quantity of themes.

> The trade off would be ok for me. What do you think?

> 

> -Sean

> 

> 

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 6
Date: Thu, 22 Jul 2004 08:35:27 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: Translation stuff for GL2
Reply-To: geeklog-devel at lists.geeklog.net

Yeah, this isn't very realistic.

--Tony

Vincent Furia wrote:


>The big down side to this method is that every theme will have to be

>translated into every desired language.  So if a site wants 7 themes

>(as comes with geeklog today) and 36 languages (as comes with geeklog

>today) under this scheme they'd have to translate each theme 36 times.

> That's 252 themes and a whole lot of extra work for translators.

>

>-Vinny

>

>On Wed, 21 Jul 2004 11:56:04 -0600, Sean M. Cunningham

><seanmcunningham at comcast.net> wrote:

>  

>

>>Hi All,

>>I was thinking that it might be kind of nice to have the translations

>>incorporated with the themes. XSilver_en, XSilver_fr, XSilver_sp, and so

>>on. Designing in my native language seems only natural and I would

>>imagine that most designers are designing in their native languages

>>also. A site that requires multiple languages would have to have the

>>translator and designer working together though.

>>I feel that this could streamline the base code and simplify the themes,

>>although it would increase the quantity of themes.

>>The trade off would be ok for me. What do you think?

>>

>>-Sean

>>

>>

>>

>>_______________________________________________

>>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