Improved Editor Plugin Architecture

[ptwobrussell]

I don't think this is news to anyone, but wanted to start a ticket to discuss the Editor's plugin architecture. Basically, I am hoping that at some point, plugins will be more standalone in that plugin code from _editor/plugins won't have dependencies on Editor.js, which appears to be the case right now.

While trying to write about plugins, I quickly ran out of creative ideas for how to tell someone to write their own custom plugin without suggesting that they hack on Editor.js (which currently has a bunch of case statements that handle some of this stuff.) Am I wrong, and there is there is a fairly simple and elegant way to create custom plugins w/o doing that?

Also, it might be worth talking about how you should and shouldn't pass in values to plugins. For example, on the EnterKeyHandlingPlugin?, I don't see a better way of specifying blockNodeForEnter than adding a call to

dojo.extend(dijit._editor.plugins.EnterKeyHandling, { 
                 blockNodeForEnter : "div"
});

sometime before the editor is parsed. Is there a better way of doing this? Should there be? (All sincere questions.)

[liucougar]

for the first issue, you can use dojo.subscribe to listen to dijit.Editor.getPlugin, look at the end of Editor.js for an example

for the second issue, you can use this:

new dijit.Editor({extraPlugins: [{name:'dijit._editor.plugins.EnterKeyHandling',blockNodeForEnter: 'div']}

[alex]

I really don't see that listening to a topic is the right way to handle this. The case statements need to go away in favor of an AdapterRegistry?. This shouldn't be so hard.

[bill]

(In [12588]) Just a testcase for adding custom plugins (against Dojo 1.0 API). Refs #5707.

[peller]

(In [12702]) Remove special cases from Editor switch, register topics for plugins instead. Apply styling to font menus. Refs #5707, Fixes #5980

[dylan]

mass move of editor issues to 1.2.