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

[Lamoureux, Robert]

I have sent Roland Mas a direct email on my ideas for the plugin environment
and I am re-publishing it here for a wider audience to comment on.  It has
the ability to hook into the events of the core system.  The SF designers
have to "sprinkle" the plugin calls at appropriate places in the codebase
but once that is done, the plugins need no other changes in the main
codebase to work.

In Tim's specific example, once a tracker has been changed, a line such as:

$PluginManager->fireEvent("tracker_updated", {event specific args 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.

My initial email to Roland briefly describing this plugin manager is below:
I would like to hear what others think, I have a zip file available for
people to look at the code involved (very small)


----------------------- original email ----------------------------

Here are some details of the design.

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

The action type specifies hoe the plugin should behave on the particular
page.  For example, I thought it would be too limiting to have just URL
links inserted on pages, so the action types support 4 values:

rlink - "Relative Link".  This is a URL to a PHP file in the plugin's home
directory (./www/plugins/Calendar) for example.

alink - "Absolute Link".  Allows the plugin to provide an absolute hyperlink
to someplace

proc - "Procedure".  Allows the plugin to specify the name of a function
(contained in the Plugin.php file). Later I would like to add the ability to
call a procedure from a PHP file loaded in the plugins directory

file - "include file".  Allows the plugin to include a PHP file from it's
plugins directory.  This would allow for "inline" content to be inserted by
the plugin.  A real Calendar plugin would then be able to render it's
calendar right in the spot it was called from.


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.  

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)


(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?  For now, this system assumes we
will modify all the appropriate pages to allow for plugin rendering.  The
good news is, this framework allows for very granular control of where
plugins display even if we get carried away with sprinkling these items
around)




The plugin manager takes the group_id or user_id along with the name of the
page from which it's being called and renders the right information from the
control file.  There is provisions for a default behavior that will happen
on any page that does not have a specific entry.  There is also a way to
block a single page from getting a plugin rendered by adding an entry with
the action type set to 'none'

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.




-----Original Message-----
From: Tim Perdue [mailto:address@hidden 
Sent: Wednesday, December 04, 2002 5:36 PM
To: address@hidden
Subject: RE: [Debian-sf-devel] Plugins thingy, draft #2 


 >Here's the state of the README.Plugins I've written so far.

Sorry I'm joining this late. If I understand the plugin architecture 
right, it essentially boils down to a method to add new subdirectories 
of isolated code to the system, and add simple navigation links so you 
can then drill down into those new subdirectories.

That sounds like a good way to accomplish that, but I'm not sure it's 
going to satisfy people's appetite for customization. For instance, I 
can see it does not solve our problem with multiple source code 
management tools, at least I don't think so. I don't see how, for 
instance, you would handle the stats gathering and management of 
multiple SCM tools using this system.

I'm a fan of keeping things as simple as possible so people can easily 
dig into it and customize it, and this should be simple and easy enough 
any could use it.

It doesn't really go into the "event driven" system that Tim Uckun 
mentioned. For instance, on update to a tracker item, I don't see any 
way of triggering my plugin at that point.

I'm not saying you should have that capability, I'm only saying it's not 
there. Adding it in puts on a whole new layer of complexity, I'm not 
sure if anyone would want to deal with.

Tim



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