All blog posts, code samples and downloads licensed under Apache License 2.0.
Close

Solving problems with CKEditor in 9.0.1FP1 and/or FP2

Oliver Busse on 08/31/2014 07:24:21 PM CEDT, filed under XSP Java 

The last two weeks I struggled with incompatibilities when using the CKEditor in applications that run on both Domino 9.0.1FP1 and FP2. The latter now uses Dojo 1.9.2 and CKEditor 4.3.2. The new CKEditor uses different Dojo attributes to control e.g. the toolbar type. I also noticed that if your server was updated to FP2 but then was reverted to FP1 the Dojo libraries of 1.9.2 and the CKEditor code 4.3.2 are still on the server - and keep being used! So I wanted to compute dynamically when to use which Dojo attribute depending on the versions your server will provide.

My solution consists of a managed bean, a faces-config definition and an example of it's usage with the CKEditor (a.k.a. the Richtext control).

// Java code to define a map containing some configuration strings for the Dojo stuff
package org.openntf.xsp.dojo;

import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;

import com.ibm.xsp.context.DojoLibrary;

public class Config implements Serializable {

	private static final long serialVersionUID = -5429830701050906773L;
	private final Map<String, String> config;

	public Config() {
		this.config = new HashMap<String, String>();
		DojoLibrary dojolib = com.ibm.xsp.context.DojoLibraryFactory.getDefaultLibrary();
		
		// get the current version of Dojo
		config.put("version", dojolib.getVersion().toString());
		// get the keyword for setting toolbar options
		config.put("toolbartype", dojolib.getVersion().toString().indexOf("1.9") == -1 ? "toolbarType" : "toolbar");
		// to be extended...
	}

	public Map<String, String> getConfig() {
		return config;
	}
}


<!-- faces-config.xml -->
<managed-bean>
		<managed-bean-name>dojo</managed-bean-name>
		<managed-bean-class>org.openntf.xsp.dojo.Config
		</managed-bean-class>
		<managed-bean-scope>view</managed-bean-scope>
</managed-bean>

<!-- example using the Richtext control -->
<xp:inputRichText id="inputRichText1"
					value="#{sessionScope.editor}">
					<xp:this.dojoAttributes>
						<xp:dojoAttribute name="extraPlugins"
							value="autogrow">
						</xp:dojoAttribute>
						<xp:dojoAttribute value="Full">
							<xp:this.name><![CDATA[#{javascript:dojo.config.get("toolbartype")}]]></xp:this.name>
			</xp:dojoAttribute>
	</xp:this.dojoAttributes>
</xp:inputRichText>

How it works

The bean stores some values in a config map. The map value of "toolbartype" stores whether to use "toolbarType" or "toolbar" as attribute name for the control. So in this case it computes the attribute name and not it's value (in this case I use the "Full" toolbar with all options).

I tried to compute the attribute name directly with the above Java code but it failed. I think the rendering phase cannot compute the correct version until the control is rendered itself so the bean solution was the alternative as it is instanciated before any rendering takes place.


Tagged with dojo java xsp xpages