API design for making Cristal & XWiki editor-agnostic

Cristal
1

As we want to allow both Cristal and XWiki user to replace the default provided WYSIWYG editor with another through e.g. extensions, we need a way to make these two projects editor-agnostic.

The proposal would be to create a TypeScript API defining some methods and types an editor must expose, and use this as a common denominator to plug any editor to any of these two projects. Each ‘official’ editor (such as BlockNote) would then be provided as a separate Node.js package. Others could be brought through extensions.

Basically, we would have: Cristal / XWiki ↔ documented API ↔ any editor implementing the API

The API is still to be designed, but would need to be carefully thought in order to not make bad initial decisions as the API will need to be backwards-compatible.

1 Like
2

Hi Clement,

Note that XWiki is already “editor-agnostic” on the server-side. See https://extensions.xwiki.org/xwiki/bin/view/Extension/Edit%20Module . The CKEditor module provides a component implementation for role Editor<org.xwiki.rendering.syntax.SyntaxContent> (hint ckeditor). And there’s an administration section https://extensions.xwiki.org/xwiki/bin/view/Extension/WYSIWYG%20Editor%20Module/#HAdministrationSection that allows you to select the WYSIWYG editor implementation to be used. There’s only one implementation available ATM, the CKEditor one, but XWiki extensions can already provide a new WYSIWYG editor implementation.

There’s no abstraction layer on the client-side currently, because we didn’t need it (badly enough so far):

  • when the WYSIWYG editor is enhancing a plain text area, we set the value of the text area and get the value from the text area
  • when the WYSIWYG editor is enhancing a DIV, we set the inner HTML and get the inner HTML from the DIV
  • the editor loading is triggered from the server-side, see for instance https://extensions.xwiki.org/xwiki/bin/view/Extension/Edit%20Module#HUsetheWYSIWYGEditorinaForm , by loading the required JS/CSS resources and marking the place (with a CSS class) where the editor should be loaded

+1 to introduce a client-side abstraction layer. I think the main needs are:

  • create an editor instance client-side (passing the element to hook to)
  • destroy the editor instance
  • get the edited content (e.g. to save it)
  • set the edited content

Thanks,
Marius

1 Like