loading table of contents...

7.5.2. Migrating Richtext Editor Dialogs

The architecture for richtext editor dialogs has changed. It is now possible to use standard CKEditor dialogs and style them with skins. The coremedia skin is available as a template which may be customized.

If you have custom CKEditor plugins that use dialogs then your old solution will not work with CKEditor 4 and you have to migrate it. The reason for this, is that coremedia shipped custom coremedia plugin for CKEditor, called 'extdialog', which patched the standard CKEditor dialogs and forwarded the calls that they would normally receive over to Ext-Dialogs and other way around from Ext-Dialogs to CKEditor. Such Ext-Dialogs could be defined in EXML and styled with CSS in the same way as other studio components. Unfortunately this blocked the posibilty for coremedia customers to use the CKEditor plugins containing dialogs out of the box.

With the upgrade to CKEditor 4 Coremedia removed the 'extdialog'-Plugin gaining the ability to use OTB CKEditor Plugins with CKEditor 4. The dialogs included in such plugins would be displayed with standard CKEditor CSS Styles, unless they are styled with coremedia skins as mentioned above.

Migration Steps

To migrate your CKEditor plugins, which include custom dialogs, you need to take following steps:

  1. Define an action (e.g. MyPluginAction.exml and MyPluginActionBase.as) and a dialog (e.g. MyPluginDialog.exml and MyPluginDialog.as).

  2. Inject CKEditor into your action by adding the following method to MyPluginActionBase.as: 

    [InjectFromExtParent]
public function setCKEditor(editor:*):void {
  ...
}

    For more on injection and inversion of control in studio see Section 7.8, “Customizing Studio using Component IoC”.

  3. Your dialog has to receive CKEditor as a config parameter 

    <exml:cfg name="editor" type="*"/>

    in MyPluginAction.exml. 

    protected native function get editor():*;

    in MyPluginActionBase.as

  4. The handler method of your action must instantiate the dialog and pass the ckEditor (that it got injected with the help of InjectFromExtParent annotation) to the newly instantiated dialog.

  5. In the EXML of the dialog you can define the components you need as well as the OK- and CANCEL-Handler for your dialog. In the base class of the dialog you can then get the reference to the CKEditor instance. The logic, that was earlier programmed in JavaScript in the CKEditor-dialog of your plugin, now should be transformed into Action Script of the base class of Ext-Dialog (MyPluginDialog.as).

  6. Now you can delete the folder with the CKEditor-dialog from your plugin as well as the following code registering this dialog from its plugin.js: 

    editor.addCommand(commandName, new CKEDITOR.dialogCommand(dialogName));
CKEDITOR.dialog.add(dialogName, this.path + 'dialogs/my-plugin-dialog.js');

    In many cases you should consider deleting your plugin, completely, if the whole logic can be ported to Action Script base classes of your Ext-Action (MyPluginActionBase.as) and Ext-Dialog (MyPluginDialog.as) that would communicate with the injected CKEditor per API calls.
Prev Up Next
 Home