Re: [Debian-sf-devel] Plugin infrastructure -- Request for comments

From:

Justin Richer

Subject:

Re: [Debian-sf-devel] Plugin infrastructure -- Request for comments

Date:

15 Nov 2002 11:17:53 -0500

I agree with this point. My suggestion would be to just have SF scan the
table of available plugins and give projects the option of using them in
addition to the built-in tools. It should mostly be a matter of querying
the 'plugins' table and looping through the resulting rows in the
correct places. We've done something similar, but less robust, with our
sf-2.5-based project here. In general, I don't think it's a good idea to
force plugins to modify existing pages, but in some places it will have
to be done. You do run into the problem of plugins stepping on each
other, then, though. Especially if someone's running a more non-standard
web-tree (as we are here).
-- Justin
On Fri, 2002-11-15 at 03:27, Arnar Birgisson wrote:
> Hi
>
> I'm not a long time sf user but having worked on similar projects with
> regards to the plugin structure I have only one comment about point 5.
>
> If possible, the plugins should not have to modify any pages not their own,
> or any files for that matter. Instead you could f.x. define insertion points
> for plugins, such as the "Public Areas", "Main menu", "Project config pages"
> (for a checkbox indicating if the group uses this plugin), "User page"
> (possibly subdivided) and plugins register themselves to be considered for
> certain insertion points. When rendering these areas, sf then selects all
> plugins that have registered themseleves for the area in question and checks
> for each one if the user/group uses it. That way, no modification to any
> files is neccary for each plugin, they only need to register themselves in
> the database.
>
> There was a posting earlier by Tim suggesting the use of a register_plugin
> function. I support this, that way with the addition of what I said above,
> the sf core system can have full control over the modifications of a plugin
> (providing plugin writers stick to protocol), and could even perform the
> creation of tables and other db objects for the plugin. That way there's even
> a possibility of the core system to keep track of neccessary data to
> uninstall a plugin, so lazy plugin writers that can't be bothered with
> writing uninstall procedures wouldn't have to.
>
> I really like the plugin idea and even though I have to agree with you on the
> calendar argument, it would certanly be useful in my companys application of
> sf. Keep up the good work.
>
> Arnar
>
> >>> Roland wrote..
> 5. A plugin should not change the existing pages, except insofar as it
> adds links to its own pages. I think these pages should reside in
> the /plugin/*/ URL-space (that is, plugin "foo" will probably put
> its files in /usr/lib/sourceforge/www/plugins/foo/), unless some
> better idea is found. Of course, these additions will have to be
> merged into the pages of the main package, but it should be just a
> matter of inserting lines like
> ,----
> | if $this_group->usesPlugin("foo") {
> | echo [Link to /plugins/foo/index.php?parameters]
> | }
> `----
> in the existing pages. Most plugins will probably only add these
> links on the project summary page and/or on the user personal
> pages.
>
>
>
> _______________________________________________
> Debian-sf-devel mailing list
> address@hidden
>http://mail.nongnu.org/mailman/listinfo/debian-sf-devel