I remember running into essentially this problem before.
Plugins like bookmark plugin could be initialized per website, but do need
access to site-specific (bookmark) data. The topictag plugin can refer to
bookmarks as well, but I think most people run with this disabled because it
is not efficient.
The instantiation and initialization model are coupled, since one expects
that the plugin may store instance data/references at initialization time,
and use it when called subsequently to process the entry. If the call to
process the entry could pass in enough contextual information to relieve the
plugin from keeping this state, it would allow sharing instances of the
plugins and initialize them only once. In other words, init should pass in
server-wide configuration information, and the call to process the entry
should pass in all contextual references necessary.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 01, 2006 11:14 AM
Subject: Re: cleanup weblog entries plugins
okay, this has been committed to the 3.0 branch.
there is one more important little change that i would like to propose
with regards to the entry plugins. the entry plugin architecture was
cleaned up quite a bit for 3.0, but one thing was left which i would like
to address. the current entry plugin interface has this method ...
public void init(WebsiteData weblog, Map model) throws RollerException;
... which initializes the plugin for the given weblog. i would like to
change this method signature to not pass in the model Map to plugins for a
few reasons ...
1. security. giving a plugin access to the model is potentially dangerous
because a plugin could then remove/modify existing items in the model or
add potentially harmful or inappropriate items to the model. we have
specifically designed the rendering model architecture to accomplish this
task. Model objects are what should be added to the rendering model, not
random items via entry plugins.
2. simplicity. i don't think plugins need the model to do their job. they
are currently only meant to take the entry content and transform it in
some way and that shouldn't require access to the model.
3. performance. technically if a plugin doesn't need to be initialized
each time with model data relevant to a given request then it would be
possible to initialize the plugins only once and then reuse them.
also note, right now the only plugin that even makes use of the model that
is passed in at init time is the Textile plugin, which i have not included
in the core src tree as a supported plugin mainly because it requires an
additional library and i think those kinds of plugins really should be
added on externally.
what do others think?
-- Allen
Allen Gilliland wrote:
for the current set of plugins I think that's fine, we can just move all
the current plugins in to the core src tree and then modify the config to
only enable a subset of them. i'll go ahead and take this approach since
it really is the easiest in our current situation.
the main reason i proposed this though is that i believe very strongly
that moving forward it's not our job to maintain all the plugins directly
in the src tree. we don't have many people who do this right now, but
eventually we want to build a user community that really does create and
share plugins and that has to happen outside of the core project. we
already have 10 plugins, what happens if the list grows to 20, 50, etc?
as long as we make it easy for people to add in a plugin then i think
it's best that they be developed and maintained outside of the core src.
-- Allen
Sean Gilligan wrote:
Anil Gangolli wrote:
Sorry for entering this conversation a bit late.
How about shipping these plugins but not enabling them by default. For
example, I'd rather they ship as part of the normal install but we just
comment them out in roller.properties.
Or we could have an admin page to enable them like for editor pages.
-- Sean
