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: Tim Perdue
Subject: Re: [Debian-sf-devel] Plugins thingy, draft #2
Date: Wed, 04 Dec 2002 19:56:29 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021123

Lamoureux, Robert wrote:
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.

Yeah, this is exactly what I was thinking. I'll say again, I'm not advocating it, because I have never seen any need or use for it, but others may think it worth pursuing.

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.

I think this is "overarchitecting", IMHO. I don't see how this is necessary, but it does add tons and tons of overhead in terms of complexity. Learning to use/write one of these plug-ins would be a lot more complex than it needs to be.

Also, it adds "yet another" coding style to the codebase. You can see throughout the codebase how things changed over the 1-2 years it was being maintained. First it was all procedural code, with a lot of hard-coded SQL all over the place. Then some of it was rewritten to separate the SQL into separate function files (pm_data.php, doc_data.php, etc), and then finally a good chunk was rewritten in OO.

In my opinion, the Tracker is the final coding and architecture style which should be adopted throughout the code. I rewrote the tracker for exactly that purpose - to show how I felt it should all look if done right.

Tim





reply via email to

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