debian-sf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roland Mas
Subject: Re: [Debian-sf-devel] Plugins thingy, draft #2
Date: Thu, 05 Dec 2002 12:42:02 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]