--- Begin Message ---
|
Subject: |
Reply to debian-sf-devel |
|
Date: |
Sat, 16 Nov 2002 11:12:48 -0000 |
Hello..
I wasn't subscribed to debian-sf-devel when you posted this message so I
don't have anything to properly reply to, so I'm replying to you directly,
maybe you could post this for me. I am subscribed now though :o)
>> 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.
>
> Interesting idea. I'm not sure it would work, though. I'll assume
>we're speaking about just adding links to plugins in the webpages. It
>is true that for some plugins there will be no parameters to the link
>apart from the group_id or user_id. But for others, I expect they'll
>need some extra parameters. For instance, if someone hacks up a
>plugin to draw Gantt diagrams, the links to it might be not on a
>per-project basis but on a per-task or per-subproject basis. So the
>links might not be fully computable without further knowledge of the
>plugin, which means patching the core files.
This could simply be a matter of definition for each insertion point. That
is, an insertion point (or a hook) on a task page would include the
group_id, task_id and any other relevant parameters. The parameters passed
to plugins utilizing each hook would be documented along with an overview of
available hooks. One could argue that this behaviour is limiting for plugin
functionality, another way would be for plugins to register their url along
with the query string they require when they sign up for a hook. That way,
plugins have full control of what parameters they recieve, without having to
modify the pages directly.
Your assumption was correct, I was at the time only talking about plugins
adding links to themselves. However, you could thake the hooks concept
further and provide hooks not only for links, but e.g. for some specialized
statistics or any other valid HTML. One possible use for such hook could be
the option for plugins to add a box to the projects page or the user page
(such as the "Latest news" box).
Arnar
--- End Message ---