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.
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). - Dave
