comments inline ...
Dave wrote:
More comments below...
>> > On 10/6/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>>section about editor configuration and I agree
>> with what you are trying to do, but I'm wondering if there is an
easier
>> way to do it. I agree that the editor names should not be jsps,
and if
>> they can use i18n then that's great but IMO not a requirement.
>>
>> Ultimately I think it would be better to see the editors function
like a
>> plugin rather than just being a jsp which has to be added to the
app in
>> a specific directory. How to do that is a little tricky and probably
>> goes outside the scope of what you are trying to do, but maybe we can
>> lay the groundwork?
>>
>> For now, what if there was just a simple WeblogEntryEditor interface
>> which defined a couple methods like getName() and
getJspLocation(). The
>> getName() method can be setup to use the resource bundle to get its
i18n
>> name if desired. We then layout the config file so that the property
>> 'weblogEntryEditors' contains a comma separated list of class names
>> which implement that interface. Then in the couple places where
editors
>> are used (settings page and new entry page) you would change the
jsps to
>> use those classes rather than the hard coded way they work now.
>>
>> This provides a little bit of infrastructure to the process of
defining
>> a custom editor without requiring much work. Then eventually we
may be
>> able to replace the getJspLocation() method with something even more
>> generic like getHtml() which could be backed by velocity or something
>> else.
>>
>> Would that work?
>
> Yes and I definitely like the idea of better defining weblog editor
> plugins,
> but I don't think what you suggest is easier from a development
point of
> view. We don't have a lot of time to wrap up this work so the
question is:
> is the configuration change I suggested a worthwhile improvement over
> what we have now? Should we do it for 3.1 and then improve the plugin
> interface concept later? I think so, but I don't really have a strong
> opinion.
yes, it is a little more time from a development point of view, but i
can help with that if time is the problem. we only have a couple
editors that we support, so i think this is manageable.
I'm pretty much out of time now. I spent way too much time fighting
Hibernate bulk-delete. So now I'm wondering, should we:
I don't mind doing part of this work if that would help. I think it's
still reasonable to do this for 3.1 and I can spend a little time to
look at it today.
1) use SQL in the migration script to switch users from editor-rte.jsp
to editor-xinha.jsp. I have the necessary one-liner ready to commit.
yep.
2) leave both RTE and Xinha both in place for now, or at least during
testing.
I am definitely -1 to this, I don't think we want to start adding new
editors to the list. In fact, I would prefer that we delete all those
old editors from svn that we no longer support and if we want them to be
kept around then put them over at roller_support.
-- Allen
the main reason why i would push for something more than what you have
in the proposal is that the way you define the "weblogEditors" property
seems cryptic to me and if we know we want to replace it then why not
just do it now?
>
>> The only other thing I don't understand from your proposal is why you
>> have a default text editor and default rich text editor, shouldn't
there
>> just be a single default editor?
>
> That's a good point, but I think its valuable to support a default
editor
> for each of the two editor types (plain and rich).
but under what circumstance would you use the default "rich text" versus
default "plain text" editors? i guess i don't see the usability angle
here because there can only really be one default editor. i guess the
other part of it is that we only support 2 editors anyways, so why do we
need to call each of them a default?
OK. I'm sold. One default is the way to go.
- Dave
