Those who have followed my blog will be aware that I posted an article earlier this year about extending the Rich Text Editor. That showed that the Rich Text Editor used an extension of a dojo class, ibm.domino.widget.layout.DominoRichText, and could be extended by defining various dojoAttributes, for example fontName as Arial, extraPlugins as [“createLink”,”|”] to add a button to create a link and a separator.
With 8.5.2, IBM introduced the CKEditor as the default Rich Text Editor instead of the ibm.domino.widget.layout.DominoRichText extension of Dojo. And, as I learned, that too can be extended, from the basics of a toolbar type through to plugins, skins and defining what the Enter key does. The editor is created using two files, both in dominojsdojo-1.4.3ibmxspwidgetlayout. The first is CKEditorWrapper, the second is xspCKEditor. The former appears to be the file that holds the CKEditor javascript itself, the latter seems to be the file that defines the implementation specific for XPages with all the settings you find in the default editor. As with all the Dojo files, it is advisable to inspect the uncompressed version.
First of all, I must prefix this article with the acknowledgement that most of the information about extending the editor does not come from my own investigation and experimentation. It’s based upon a response by Teresa Monahan of IBM to a query I posted on the 8.5.2 Managed Beta Forum earlier this year. However, that was the beta, and as all articles on the beta covered, there are never any guarantees that beta functionality will be included in the Gold product. So I’ve confirmed that all the information Teresa supplied for the beta is still correct for 8.5.2 GA.
Unlike 8.5.1, the CKEditor is used as default, so there is no need to define a dojoType. That said, if you should want to keep the original editor, you can still add a dojoType attribute set to ibm.domino.widget.layout.DominoRichText. (To find out more about this widget, look at the javascript file in dominojsdojo-1.4.3ibmdominowidgetlayout.)
As with 8.5.1, though, extending the CKEditor is done by adding Dojo attributes. The simplest is toolbarType. This allows three toolbars with differing levels of functionality. They are Slim, Medium, or Large. Medium is the toolbarType that is implemented by default, so unless you’re overriding the basic toolbarType in a theme, there is no need to define the toolbarType as Medium.
However, on occasion you may wish to override the toolbar. For example, all toolbars include a button for emoticons, and you may wish to remove that from some applications. If you wish to do so, you can create your own toolbar by adding the Dojo attribute toolbar. This should be defined in SSJS as an array of plugins you want to make available, e.g.:
var myToolbar=”[[‘Font’,’FontSize’], n”;
myToolbar += “[‘Preview’,’Bold’,’TextColor’,’BGColor’],n”;
myToolbar += “[‘Italic’,’Underline’,’Strike’,’-‘,’Subscript’,’Superscript’]]”;
return myToolbar
Within the main array, [‘Font’,’FontSize’] creates a group of buttons. The next array creates a new group of buttons. A separator to start a new group can also be defined explicitly with the ‘-‘ toolbar option. You can find out the various plugins available by inspecting the DOM in, for example, Firebug. Alternatively, they are listed in the CKEditorWrapper.js. If including a plugin that is not in the 3 basic toolbarTypes, you need to make sure the plugin is loaded by using the extraPlugins dojoAttribute.
I have not tested this, but you can also control the functionality of the enter key with the enterMode dojoAttribute. The available values are:
1 – a new paragraph is created, the default functionality.
2 – a
tag is inserted.
3 – a new
There are also three alternate skins available, to be found in dominohtmlckeditorskins. These can be changed by defining the skins dojoAttribute to, e.g. kama, office2003, or v2. Additional skins can be created using the same format as the ones provided or reviewing this documentation (albeit a little out-of-date). Bear in mind that there is currently a limitation that all skins need to be in the same folder as the three available skins.
This is the information Teresa kindly supplied, and for those of you who were in the managed beta program, here is the post. I’ve also found by experimentation that other settings can be managed using dojoAttributes, e.g. toolbarCanCollapse. This is, by default, set to false but can be changed to true. I would advise inspecting the javascript files and experimenting to find out what additional settings are available. But this should give plenty of flexibility for developers.
Odd. I’ve tried setting the toolBar attributes. Anything other than the default (no specification) disables the toolbar completely. I’m on 852 server & client. Also the image upload to existing documents seems to fail (new documents are fine). Has this happened to you?
Toolbar seems to work for me, on Firefox and IE. The Font and Font Size appeared to be greyed out, but did work. Have you got any other settings enabled that might be conflicting?
The inline images seem to work if I upload them to the server first. I admit I haven’t used it extensively yet though.
Hi Paul,
Great post. You seem to be one of the few, if not the only person blogging about this new editor!
Can I ask have you successfully used the image upload feature yet? We’re having a problem with the image dissappearing after a while, maybe after the session expires, with this error in the log…
30/09/2010 12:07:15 HTTP JVM: !err.PersistenceServiceResourceProvider.Errorwritingtopersistedcontenttor!. For more detailed information, please consult error-log-0.xml located in D:/Domino/data/domino/workspace/logs
I’m trying to find someone who has this working to see if it’s limited to our implementation, or a bug with the release. May be some kind of file system or JVM security issue
Many thanks!
Martin
@Martin I’ve only tried inserting an image inline (first using the upload to server button), I haven’t used the editor extensively yet. I’ll see if I can reproduce your problem.
It’s worth raising a PMR about it (if you haven’t done already). It sounds like it could be a problem beyond the basic CKEditor, associated with uploading the image to the server and keeping the location.
@Paul FYI I found a solution here to my issue…
{ Link }
“We have an existing issue with images submitted via the ckEditor in 852 that we’re seeking to address as soon as possible and get a fix into the first fix pack for 852. So if you’re hitting this it’s recommended that you log a support call for it and reference this bug number (SPR#) PHAN88HEKA. With your help we can get this addressed quicker.
There is a workaround, though this will not be to everyone’s liking as it effects performance.
Go to the Application Properties and on the XPages tab set the ‘Server page persistence’ to either “Keep pages in memory” or “Keep only the current page in memory”. You will need to apply this on an app to app basis.”
We have a problem displaying the richtext content properbly when the content contains a url like explained in this forum.
Have you seen this before?
{ Link }
Thanks in advance for any hints.
regards
Staale
Staale
See my response on the forum. It looks like this may have been rich text originally saved in Notes Client, is that right?
If you’re trying to edit in Notes and web and get full fidelity, that doesn’t seem to be on the horizon for XPages. The direction appears to be to use XPages in the Notes Client, although that is only my perception. If you’re wanting browser-client rich text fidelity, you’ll probably need a third-party product like CoexEdit from Genii Software. I haven’t used it myself, but only know that is an area Ben Langhinrichs has been working on for more versions of Notes than I’ve been developing!