Symptom

After installing EditLive! for IBM WCM, the default editor is still used when using inline editing. When using the standard WCM interface, EditLive! is correctly used to edit rich text sections.

Cause

The WCM rendering portlet which provides the inline editing has a separate configuration option for which rich text editor to use. In most cases, this setting is correctly changed to use EditLive! when installing but in certain environments the setting may revert to the default editor.

Solution

1. Log in as the portal administrator.
2. Go to Portal Administration –> Portlet management –> Portlets.
3. Search for portlets starting with Web.
4. Click on the “Configure Portlet” button (displayed as a spanner icon) for the “Web Content Viewer” portlet.
5. Set the value of the WCM_RICH_TEXT_EDITOR field to “EditLiveJavaEditor.jsp” (without the quotes). If the field is not present, add it.
6. Save the changes.

EditLive! should now correctly load in both the standard editing form and in the inline editing view.

In many ways Java has a magnificent partnership with browsers operating on Mac. However, a partnership can never be perfect and Java and Mac is no exception.

One limitation of Java applets running in Mac browsers is that certain key combinations are consumed by Mac OS X and never passed to Java. One example that can be easily seen in EditLive! is when you attempt to open either the Edit or Insert menus via their respective mnemonics (option + E and option + I).

For developers wishing to circumvent this unfortunate limitation a solution can be found by changing the name attribute for menu configuration file elements. Adding the string & before a letter in the menu name will set this letter to be the new mnemonic.

For example, here is a snippet from an EditLive! configuration file where a menu has been specified that displays the text Edit. This menu has the letter D specified as the mnemonic.

...
<menu name="E&amp;dit">
   …
</menu>

Note: changing the name attribute for a menu configuration item from it's default internationalized version to a custom string value will cause the menu item to appear the same for each user regardless of their locale.

A new feature we've whipped up for the EditLive! 6.2 release is inline editing which allows users to select which portions of rich text they wish to edit in a webpage, rather than loading a new instance of EditLive! for each rich text field.

Implementing inline editing improves your end user experience through the following benefits:

• Faster loading of pages
• Less system resources consumed
• Cleaner, seamless editing interface
• Makes providing seamless inline editing to users extremely simple.

To integrate the EditLive! Inline Editing interface, follow these 3 easy steps:

Step 1) Include both the editlivejava.js and inlineEditing.js script files in your webpage.

<script type="text/javascript" language="JavaScript" src="editlivejava/editlivejava.js"></script>
<script type="text/javascript" language="JavaScript" src="editlivejava/inlineEditing.js"></script>

Step 2) Define each rich text area in your webpage as a DIV html element.

<form>
   …
   <div id="richText1" style="height: 550px;" ><p>div content</p></div>
   …
   <div id="richText2" style="height: 550px;" ><p>div content</p></div>
   …
</form>

Step 3) After the <form> element containing your DIVs, create a script block to define your instance of EditLive!. Add each inline editing section via the addEditableSection API.

…
</form>
<script language="Javascript">
// set the width and height of the editor to expand 100% within the selected DIV.
var editliveInstance = new EditLiveJava("editliveInstance", "100%", "100%");

// set the download directory (the location where the jar file containing the applet lives)
editliveInstance .setDownloadDirectory("editlivejava");

// set the configuration file (start with the sample one).
editliveInstance.setConfigurationFile("editlivejava/sample_eljconfig.xml");

// add the DIV with the id 'richText1'
editliveInstance.addEditableSection("richText1");

// add the DIV with the if 'richText2'
editliveInstance.addEditableSection("richText2");
</script>

This will produce a simple implementation of the inline editing solution for EditLive! When the user clicks in one of the registered
DIVs, an instance of EditLive! will appear in it's place containing the HTML contents of the DIV. When the user clicks into another
registered DIV, the instance of EditLive! will move to the newly selected DIV, leaving behind the updated content in the
previously selected DIV.

You can use any of the normal load time and runtime APIs with EditLive! to configure it as required, simply include them in the script block like normal.

You can also control whether or not EditLive! applies its CSS to help users identify editable DIVs or if you want to simply use your own with the setEditableSectionCSS API.

The Ephox integrations into IWWCM allow developers to load different configurations of the editor based on the user.

This article outlines how to achieve this functionality in the Ephox integrations into IWWCM 2.5/5.1/5.1.0.x.

Step 1) Create the Desired Configuration Files
EditLive! configurations are specified by using an EditLive! Configuration File. Ephox provides a free of charge tool for easily creating and editing these configuration files. This tool can be downloaded from the Ephox website at http://www.ephox.com/product/editliveforjava/configuration/6.0/ConfigTool.jnlp.

Create a new configuration file for each desired user or user group. Give each configuration file a unique name (e.g. adminConfig.xml, docReviewerConfig.xml).

Step 2) Edit the Ephox Integration to Define the Current User
Open the ephoxDefineUser.jsp file located in the ephox/instantiation directory for your IWWCM installation.

For example:

IWWCM 5.1/5.1.0.x:
C:\IBM\PortalServer\installedApps\WCM_Authoring_UI__PA_1_0_CH.ear\PA_1_0_CH.war
IWWCM 2.5:
C:\IBM\PortalServer\installedApps\ilwwcm-aut_ng-portlet_UI__PA_1_0_CH.ear\PA_1_0_CH.war

Use the work.getUserProfile().getUsername() call to print the user's name.
Use the work.isMemberOfGroup("NAME") call to check if the current user belongs to the specified group.

A combination of these calls can be used to define which configuration file is called. For example, the following code would catch whether the user belonged to the "wpsadmins" user group, or failing that, whether the user's name is "wpsguest".

<%
    if(work.isMemberOfGroup("wpsadmins")) {
        // load configuration file A
    } else {
        if(work.getUserProfile().getUsername().equals("wpsguest")) {
            // load configuration file B
        } else {
            // load default configuration file
        }
    }
%>

Step 3) Define the Configuration Files
Finally, use the setConfigurationFile load-time property for EditLive! to specify your EditLive! configuration file. Use the portletResponse.encodeURI Java call to generate a reference to the ephox/editlivejava directory in your IWWCM installation in order to correctly reference the desired configuration file.

<%
if(work.isMemberOfGroup("wpsadmins")) {
    out.println(eljNamespace + "elj.setConfigurationFile(\"" +
        portletResponse.encodeURI("/ephox/editlivejava/adminConfig.xml") + "\");");
} else {
    if(work.getUserProfile().getUsername().equals("wpsguest")) {
        out.println(eljNamespace + "elj.setConfigurationFile(\"" +
            portletResponse.encodeURI("/ephox/editlivejava/docReviewerConfig.xml") + "\");");
    } else {
        out.println(eljNamespace + "elj.setXMLURL(\"" +
            portletResponse.encodeURI("/ephox/editlivejava/standard_eljconfigxml.jsp?editorName=" +
            eljNamespace + "&directoryRef=" + directoryRefString) +
            "&jspContext=" + URLEncoder.encode(URLEncoder.encode(jspContext)) +"\");");
    }
%>