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
