Opened 14 years ago

Last modified 10 years ago

#5707 closed defect

Improved Editor Plugin Architecture — at Version 13

Reported by: ptwobrussell Owned by: alex
Priority: high Milestone: 1.7
Component: Editor Version: 1.0
Keywords: refactor Cc: liucougar, alex, Adam Peller
Blocked By: Blocking:

Description (last modified by bill)

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

Change History (13)

comment:1 Changed 14 years ago by 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']}

comment:2 Changed 14 years ago by liucougar

Component: DijitEditor
Owner: set to liucougar

comment:3 Changed 14 years ago by alex

Milestone: 1.1
Owner: changed from liucougar to alex
Status: newassigned

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.

comment:4 Changed 14 years ago by Adam Peller

Priority: normalhigh

comment:5 Changed 14 years ago by bill

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

comment:6 Changed 14 years ago by Adam Peller

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

comment:7 Changed 14 years ago by dylan

Milestone: 1.11.2

mass move of editor issues to 1.2.

comment:8 Changed 13 years ago by alex

(In [14733]) first in a set of large-ish merges to address issues related to the iframe refactor. This patch shortens the existing code, adds some documentation, and adds the first handling of selection saving when focus is changed. Refs #6582. Refs #5707 !strict

comment:9 Changed 13 years ago by bill

Description: modified (diff)
Milestone: 1.21.3

comment:10 Changed 13 years ago by bill

Component: EditorDojoX Editor

comment:11 Changed 13 years ago by Adam Peller

Component: DojoX EditorEditor
Keywords: refactor added

comment:12 Changed 13 years ago by bill

Milestone: 1.3future

comment:13 Changed 11 years ago by bill

Description: modified (diff)
Milestone: future2.0
Priority: highnormal

You certainly don't need to modify Editor.js to register a plugin, but I agree that using dojo.subscribe() is strange. I thought Cougar said there was some reason, like that Editor wasn't loaded yet when the plugins were loaded, so they couldn't just register themselves? I don't see why that would happen though.

AdapterRegistry doesn't seem right either since all we really need is a dictionary mapping plugin name (short name like "createLink") to plugin. Actually, I'm not sure why plugins need to be registered at all (except to support that short name --> proper name mapping).

In any case, marking this for 2.0 to decide then.

Note: See TracTickets for help on using tickets.