RE: [Debian-sf-devel] Plugins thingy, draft #2

[Lamoureux, Robert]

Great.

I sent a previous note before I read this one.  Sorry for the extra Inbox
items to all.


It sounds like we're reaching middle ground where the "design" is being
optimized to the best benefit of all (minimum complexity, maximum
functionality).  I am happy to see what Roland's latest version includes and
it will satisfy my requirements today and looks good for the ones I don't
know of yet :)



-----Original Message-----
From: Roland Mas [mailto:address@hidden 
Sent: Thursday, December 05, 2002 6:42 AM
To: address@hidden
Subject: Re: [Debian-sf-devel] Plugins thingy, draft #2


Lamoureux, Robert (2002-12-04 17:52:52 -0500) :

[...]

> In Tim's specific example, once a tracker has been changed, a line 
> such as:
>
> $PluginManager->fireEvent("tracker_updated", {event specific args 
> $PluginManager->array});
>
> Would be executed.  The plugin manager would see which plugins have 
> "subscribed" to the event and would execute code based on the rules 
> that the plugin defines.

You'll be glad to hear that this is almost exactly what I implemented
yesterday night.

> #1 Each plugin provides a control file {plugin_name.ctl} that controls 
> how the plugin works.  This control file is similar to a language file 
> in that you can specify a page followed by an action type and then the 
> action details.  What this means is that the plugin can behave 
> differently depending on which page it is being displayed on.

I think this is too complex, and I just kept the idea of an initialiser
file.  When the PluginManager loads the plugins, it does a
require_once() on all the initialiser files that are installed.  These files
have to somehow or other call a RegisterPlugin() method, passing it an
object of the Plugin() class (or more probably a subclass of it).  This
object will be handled opaquely by the PluginManager object, and all the
intelligence it needs can be hidden from the core code. 

> The action type specifies hoe the plugin should behave on the 
> particular page.

[...]

  I think it's too complex.  I think it's better if the plugin object itself
decides what to do based on the sole "hook" name and the parameters it
receives.

> The PluginManager's job is to load all the plugins from the database 
> as well as the group_plugin information and the user_plugin 
> information.

  Yep.  It does that.

> Then on any and all of the pages that the SourceForge designers see 
> fit, we should add calls to 
> $PluginManager->renderGroupPlugin($group_id, $pagename, $args) or 
> $PluginMangager->renderUserPlugin($user_id, $pagename, $args)

  Actually, it's more of a $PluginManager->RunHooks($hook_name,$args).
The hook names will have to be different on all pages and all locations in
pages, but that shouldn't be hard.

> (This is my biggest issue/question that you are struggling with as 
> well).  DO we allocate a fixed spot on every page for plugins or how 
> do we alow them to place themsleves anywhere they want?

  Not *a* fixed spot, just a few fixed spots.  For instance, in /my/, these
spots could be the user menu (currently showing "My personal pag
| Diary & notes | Account management"), the top/bottom of the
first/second columns, the bottom of the page.  This idea gives six hooks,
for instance my_usermenu, my_topcol1, my_botcol1, my_topcol2, my_botcol2 and
my_bottom.  When the /my/ page is displayed, these hooks are called at their
respective locations.  Depending on the implementation of the plugin that
registered itself for these hooks, thos could result in links, text, images,
whatever.

> I also added the capability to handle language specific issues.  A 
> plugin provider should also provide language files as part of the 
> plugin and depending on what the current langauge is, the plugin will 
> load the correct language file in the global Language object. I think 
> some work needs to be done here with regards to logged in versus 
> logged out, but should be easy.

  Yes, I haven't worked on that yet.  I will, eventually, but I first want
to finish this "plugins-with-hooks" implementation.  It should be mostly
complete, but I haven't tested it yet.  I'll try to commit that soon for all
to see, and then test and debug and add features.  I'll also have to rewrite
the README.Plugins accordingly.

Roland.
-- 
Roland Mas

Latitude 43.60039° N / Longitude 6.99555° E


_______________________________________________
Debian-sf-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/debian-sf-devel