Support for CKEditor as an upgrade to FCKeditor has been desired for some time within the Sakai community. Perhaps most importantly, it addresses aaa a long standing lack of keyboard accessibility. The benefits also include performance, functionality, and ongoing maintenance of the software.
There has been work to provide this support and, at the same time, reduce the effort to integrate further editors or UI toolkits. This document provides a technical overview of the methodology used, status of the work, and implementation advice for those interested in working with other UI technologies or editors.
To achieve the goals of adding support for CKEditor and simplifying additional implementations and maintenance, some modifications have been made and some new components have been added. Namely, the portal (
SkinnableCharonPortal) now renders script tags for the active editor, and the determination of which editor is active is centralized in the
EditorRegistry, rather than distributed across UI binding layers.
The initial integration / refactoring is complete and documented. It is tracked in JIRA as SAK-17880. It is implemented in trunk (2.9) across the various modules and also included within 2.8.x. There are certain to be some bugs found in testing and they should be reported in JIRA and linked to SAK-17880 as related issues. Issues and concerns should be recorded on the Outstanding Issues page during 2.8 QA to have a single point of reference and to avoid duplication of work.
Tools can assume that the active editor's script will be loaded in the document head and that the correct launch code will be available as the
sakai.editor.launch() function. This reduces the implementation requirement for a UI toolkit to the ability to accept the header and footer material from the portal and to render an inline script tag that calls the launch function with the appropriate textarea ID and any appropriate configuration settings. If the UI toolkit should produce the entire document, the URLs and inline script to configure the correct editor for a tool placement are available via utility to be rendered as needed.
There is also a convenience mechanism that allows static script URLs to be embedded, where the request is redirected to the active editor. This could, for example, be used to place a static HTML form somewhere and still have access to the active editor under the
sakai.editor.launch() function, without being rendered as a traditional tool or even being in the JVM.
It is important to note that the existing UI support within Sakai has been upgraded to use this mechanism. This means that existing tools need only be rebuilt (with updated dependency versions) to take advantage of this. There need be no code changes and all Velocity macros, JSF tags, and so on will continue to function.
Each editor is now responsible for supplying its own launch function (rather than being implemented in the UI technology binding). This function will be called consistently as
sakai.editor.launch(textareaId, config). There is also a value supplied for supporting file browsing, where
sakai.editor.collectionId contains the path to the collection in Resources (Content Hosting) for the active site. If the site is unknown, this will be the path to the user's My Workspace Resources.
In addition to providing a script that implements the launch function, the editor must be registered with the system. This is done by implementing the
Editor Java interface and registering with the
Editor interface has a set of simple methods that return Strings to identify the editor, the paths to the main editor code and launch script, and any inline bootstrapping script that should be included before the editor is loaded. The
EditorRegistry is available as a bean (
org.sakaiproject.portal.api.EditorRegistry), so it can be injected or retrieved via the
Because the usage and implementation of the editor is broad, a number of modules are affected. These changes are:
EditorRegistry, enhancements to the
PortalServiceinterface and implementation, and exposure of head matter in the default portal,
SkinnableCharonPortal, so all tool UI technology can access the simpler binding mechanisms.
This work has an umbrella JIRA issue: SAK-17880.
The new implementation consults the same system-wide option as before,
wysiwyg.editor. It can be set to
ckeditor to select CKEditor for the entire instance. The default for the 2.8 release line will remain set to FCKeditor. Site properties are also checked so that a site with a
wysiwyg.editor property can override the default for early adopters, testing, or special site needs.
See this separate page for more information