Thats a good point. Given that in the current model it's expected that
the plugin is initialized each time its used we may not be able to
follow the init once strategy. It would be nice if we can work towards
that though.
In any case, the bigger issue is if we can remove access to the
rendering model in plugins. I still think that's important and
something we should do for 3.0.
-- Allen
Anil Gangolli wrote:
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
