Dave wrote:
Comments below...
On 10/10/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Dave wrote:
> On 10/6/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>> +1 on the Xinha editor.
>>
>> Although, one thing you didn't talk about in the proposal is the
>> migration path for users currently using rte. You can't just remove
>> that editor from the list and add the xinha editor and that's it.
>
> Please check the proposal again. I added a section on improving the
> editor configuration and changing out the old editor using SQL.
I read through the new 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.
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?
-- Allen
- Dave
