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

[Lamoureux, Robert]

Another 2 cents worth from me.

I agree with the philosophy of clean, well-organized code such as Tim's
Tracker code.  The issue of potentially over architecting come from the fact
that since the requirements (for plugins) are not known beforehand, the
system must be designed with as much flexibility as possible up front.  It
is exactly this flexibility which allows the code to maintain it's "shape"
over time without turning into spaghetti as people refine their thinking.

The ability to handle any potenetial use-case for plugins has in fact
created a framework that looks complicated.  But to implement a "simple"
plugin is simple.  Implementing a complex plugin is harder, but at least
it's possible.

Here is where I started.  I assumed that the notion of a plugin framework
was valid.  (As a matter of fact, it is a requirement for me in my corporate
environment to provide other tools such as timetracking, project reports not
currently supported, etc).  From that point, I looked at what Roland had
initially proposed and I felt the model of having to modify the core
codebase was going to be a problem for the end users who embraced the plugin
model strongly.

This is an alternative that addresses those concerns.

Again, my assumption is that we all agree that a plugin model is necessary.
Given that, what does the debian-sf developer community think about the two
models out there so far....



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


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



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