Allen Gilliland wrote:
*snip*
I think you are on the right track. Are you going to propose this for
4.0 or later?
I would like to get it done for 4.0 because it's one of the things that
we want to get fixed up on our site and I already have the work done in
my workspace. I think the work is small enough that it doesn't really
need a full proposal, this is the list of changes and additions ...
1. Added new column 'plugins' to roller_comment table, varchar(255).
2. Added new attribute 'plugins' to WeblogEntryComment pojo, including
mapping elements in jpa and hibernate mapping files.
3. Added new interface WeblogEntryCommentPlugin in
business.plugins.comment package. Interface has 1 method,
render(comment) which returns a string of the transformed content.
5. Added 1 new comment plugin, AutoformatPlugin which takes plain text
and formats it using html. This is basically a copy of the convert
linebreaks entry plugin as far as functionality goes.
6. Added 2 new methods to PluginManager and PluginManagerImpl.
applyCommentPlugins(comment) which returns a string, and
getCommentPlugins() which returns the list of plugins.
7. Added new property 'comments.plugins.classnames' in roller.properties
which lists the configured comment plugin classes.
8. Added new runtime property 'users.comments.plugins' which is a comma
separated list of the plugins which are enabled.
9. Modified CommentServlet to basically call
comment.setPlugins(runtimeConfig.getProp('users.comments.plugins')).
This basically applies whatever comment plugins are configured to the
specific comment as it gets saved.
10. Modified Comment pojo wrapper so that the call to getContent()
actually applies plugins before returning output.
11. Unit test for AutoformatPlugin.
Things that I still need to do ...
* Add to the current upgrade process to set roller_comment.plugins =
'AutoFormat Plugin' if the installation is currently using comment
autoformatting.
* Add a way for site admins to enable/disable comment plugins via the
global settings page.
* Cleanup current comment macros and move logic out of macro and into
pojo wrapper. We already to html escaping in the pojo wrapper, but we
also need to do a couple other things.
That's it. Pretty straight forward really.
One thing that I didn't mention but is probably worth saying ... it's
also possible to design things a bit differently such that instead of
saving comments unmodified and then applying reformatting plugins as
they get displayed, we could apply the plugins on the incoming comment
and save the transformed version.
Each approach has it's own benefits. Applying plugins on the incoming
comment simplifies things quite a bit because we no longer need to add
the 'plugins' attribute to the db or pojo and it would improve
performance a fair amount since we wouldn't need to apply XX plugins per
comment during rendering. The downside is that since you modify the
comment before saving it you have no way of getting back to the original
comment if you wanted to, although that's not likely to be necessary.
I kind of like the idea of just applying the plugins once as the comment
is being submitted and then not having to worry about it after that, but
the solution I detailed above is slightly more flexible.
Any preferences one way or the other?
-- Allen
-- Allen
- Dave
