Earlier in the month, I wrote about some of my preliminary experiences dealing with the fallout of the switch from CKEditor to TinyMCE in Domino 14.5. In that post, I talked about some of the ways to deal with covering both, but I only casually mentioned one of the severe limitations in the TinyMCE Dijit implementation: unlike the CKEditor version, it doesn't let you provide anything other than strings for properties. That's fine for a lot of things, but that means that complicated toolbars aren't settable, nor are boolean properties like paste_as_text. If you've ever dealt with users and the sorts of things they want to put into rich text fields, you might understand why that parameter is useful.

I wanted a way to configure this in a way that is reasonably global and reasonably light-touch, ideally in a way that would leave older customizations working on pre-14.5 servers. I've come up with a tack that I'm mostly happy with, though it still has some limitations.

The Tack

The route I'm taking now is sort of similar to CKEditor's customConfig property, but uses the Dojo module system. I'm subclassing the ibm.xsp.widget.layout.CKEditorWrapper class (still the name when using TinyMCE) and using that as a way to set other init properties. There are a few steps for this.

Module Path

First off, we'll need to register a custom Dojo module path. Unfortunately, this isn't settable in themes for some reason, so I dropped this code in the common layout custom control:

1
2
3

<xp:this.resources>
	<xp:dojoModulePath url="example/widget" prefix="example.widget"/>
</xp:this.resources>

Theme

Then, I cracked open the app's theme and configured it to apply a dojoType to rich-text fields on Domino 14.5+:

1
2
3
4
5
6
7

<control>
	<name>InputField.RichText</name>
	<property>
		<name>dojoType</name>
		<value>#{javascript:parseInt(session.evaluate('@Version')[0], 10) &gt;= 495 ? 'example/widget/CustomTinyMCE' : ''}</value>
	</property>
</control>

This will work except in the uncommon case where you're already setting a dojoType for your rich-text fields... if so, you may have some more work to do, or you may just want to set <property mode="override"> there.

JavaScript

Finally, make a JavaScript file named "example/widget/CustomTinyMCE.js" in your NSF. I recommend making this a File Resource and then using the Generic Text Editor to edit it - that one supports newer syntax and is a bit less crash-prone than the default Designer JS editor. Set the contents thusly:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

define(
	'example/widget/CustomTinyMCE',
	['dojo/_base/declare', 'ibm/xsp/widget/layout/CKEditorWrapper'],
	function(declare) {
		return declare('example.widget.CustomTinyMCE', [ibm.xsp.widget.layout.CKEditorWrapper], {
			constructor: function () {
				this.opts.paste_as_text = true
				this.opts.toolbar = 'undo redo | cut copy pastetext'
			}
		})
	}
)

And customize at will. this.opts is set by the superconstructor to the contents of any dojoAttribute or attr properties on your component, so anything you set here will override what's set there. This can be useful in particular for things like code that sets the toolbar shorthands like "Large". Here, I just use a string for the toolbar, but, this being JavaScript, you are free to use the structured syntax.

Further Customization

The values you set in this.opts here will override anything set by dojoAttributes or in the default config HCL provides, so you have pretty free reign here. You could also use that for your own custom configurations if you have different needs on different pages - read the values in this.opts and then apply different configuration based on that. This would, admittedly, have been a nice touch in the case of the "Large"/"Medium"/"Small" toolbar shorthands.

Overall, I think this is a pretty reasonable approach. I wish that you could register dojoModulePaths in theme files, but the need for that could be worked around by moving the JavaScript to an OSGi plugin with more-predictable paths. This centralized route also leaves room for alternate customizations in the case that HCL switches the RT editor again in the future.