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.
I don't mind reorganizing them into a different package and even a different
jar but I'd really like to ship them along with Roller.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 31, 2006 9:07 AM
Subject: Re: cleanup weblog entries plugins
Dave Levy wrote:
I can see why you create your lists as you do, but I agree with both the
amendments. I use the topic plugin all the time and occasionally the
smiley plugin. (I will document it some time and would use it more if I
knew how to invoke some of the odder smileys (particularly the smug
one.))
Actually, the smiley plugin would be one of the harder ones to remove
since it also has images in it, so maybe we should just leave that one as
well.
I personally think the ConvertLineBreaksPlugin produces terrible HTML and
is hard to incorporate into a theme and inhibits the formating of code
and tables (which I also oppose in blog articles), so would suggest that
it is an extra not core.
I think that's just a case where you do things that don't work well with
the plugin and so it makes sense that you don't apply it. I still think
it's valuable to most people and in the years of blogging that I've done
I'd say that 99% of the time I just write paragraphs and include <A> and
<IMG> tags and that's it, so this plugin is very useful in simply taking
plain text paragraphs and converting them to html. I have never once put
a <table> in an entry and i don't think most people do.
The customers, i.e. people who make the plugins available for use are the
site managers, but removing it would mean that people will have to learn
HTML. You can survive with <P>, <A> and <IMG> though how hard is that?
The point of removing them from the Roller core is because they are things
that possibly *shouldn't* be enabled by default, they are plugins and
hence are meant to be added on to extend functionality. I think that we
would technically be justified in removing all of them and forcing all
admins to manually pick and enable all the plugins they want, but that
seems unreasonable.
So this is what I am going with unless there are other opinions ...
keep in core:
ConvertLineBreaksPlugin
ObfuscateEmailPlugin
TopicTagPlugin
SimleyPlugin
make optional:
WikipediaLinkPlugin
GoogleLinkPlugin
TextilePlugin
AcronymsPlugin
BookmarkPlugin
I plan to do this later today.
-- Allen
Dave Johnson wrote:
On 8/29/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
2. Move all plugins which are shipped with Roller into the core src
directory so they are actually part of the main build.
3. Remove all plugins which are *not* going to be shipped with Roller
from being included in a standard build. They can stay in the contrib
area and just be built separately, or possibly moved elsewhere like the
Roller support project.
anyone object to any of these steps?
+1 on this idea
keep in core:
ConvertLineBreaksPlugin
BookmarkPlugin
ObfuscateEmailPlugin
I'd replace the BookmarkPlugin with TopicTagPlugin, based on popularity.
- Dave
