Create your custom attribute editor (part 5)

Add custom settings to your editor

We learned in previous parts how property editors work, how to write a custom editor, a widget for the editor, and how to test it.

In this part, we will learn how to add custom settings to your editor, located right below the editor select box in the Entry Template Designer tool. It looks like this: (remember, in our current version there is nothing)

ICN_editor_settings_7

Settings are part of the the editorConfig you are injecting in the ControlRegistry object (ControlRegistry.editors.editorConfigs array). The config can have a settings property, which is an array of object defining the settings. Here is how it looks like:
Continue reading

Create your custom attribute editor (part 4)

To summarize what we’ve done so far:

  • In part 1, we created a new plugin and learned how to inject a custom editor in the ICN configuration
  • In part 2, we wrote our custom editor
  • In part 3, we wrote our custom widget

We will now deploy the plugin and use our custom editor in an entry template. Then we will add a new document using this entry template, and we should see our custom editor in used.
Continue reading

Create your custom attribute editor (part 3)

Create the widget

In part 2, we learned how to write the Editor and how to inject it in the ICN configuration. In this part, we will write the widget used to edit the property value.

For this tutorial , we will focus on a simple widget, composed only of a text box. I will add an extra part at the end of this tutorial describing a more complex widget.

HTML Template

As you may already know, a dojo widget (dijit) is made of two files, the dojo class (JavaScript) and the template (HTML). First, let’s create the html template, defining our widget presentation. Create the file customEditorPluginDojo/widgets/templates/MyCustomTextWidget.html and paste in it the following content:


<div class="myClass">
    <!-- The node that should get the focus should have the focusNode attach point. pvr/widget/_Property._createEditorWidget needs this because it wants to set the aria-labelledby on it -->
    <input data-dojo-type="ecm.widget.ValidationTextBox" data-dojo-attach-point="inputField,focusNode" name="${id}_inputText" id="${id}_inputText" />
</div>

Continue reading

Create your custom attribute editor (part 2)

Create the editor

In part 1, we learned how to inject our new editor in the list of existing editors in order to use it in the Entry Template Designer tool. That’s sweet, but we still don’t have a custom editor. We could, of course use the existing ones (take a look at the pvr/widget/editors folder) if they fit our needs, but if not, this is how to create a new editor from scratch.

Basics

The basic idea is quite simple, an editor is a dojo widget, extending :

  • the widget used for editing (TextBox, CheckBox, Select, Custom Widget, …): Allows you to edit the value of the property
  • The pvr/widget/editors/mixin/_EditorMixin class: Takes care of all communication between the property object and your editor widget

So let’s start with creating our editor file customEditorPluginDojo/editors/MyCustomEditor.js. The skeleton of our editor will be:
Continue reading

Create your custom attribute editor (part 1)

In this series of posts, we will learn how to develop and use a new attribute/property editor in your Entry Template layout.

ICN_editor_settings

This is not as easy as it first sounds, so I will split this tutorial in 6 parts.

Here is the summary of all parts, they should be taken in order.

  1. Part 1: Principle and configuration injection
  2. Part 2: Create the editor
  3. Part 3: Create the widget
  4. Part 4: Deploy and test
  5. Part 5: Add custom settings
  6. Part 6: Create a fancier widget and extra editor configuration

First part, how is it all connected

It’s good to start with some basic comprehension of how the editor mechanism works in ICN. The most important class is the ecm/model/configuration/ControlRegistry class

Everything starts with this class, this is the main registry storing the configuration of the editors. This consists of:

  • The editors configuration: Label, class, options
  • The mappings: types/cardinality to editor and free/choices/coumpound to editor

This is how looks this class:
Continue reading

Upgrade from ICN 2.0.3 to 2.0.3 FP5

Note: This post is superseded by its new version.

Here is a way to silently upgrade from IBM Content Navigator 2.0.3 to 2.0.3 FP5. You can use this right after using the CPIT installer to be up-to-date with your ICN version. You need at least ICN 2.0.3.0 to upgrade to ICN 2.0.3 FP5.

In the same folder you copied 2.0.3-ICN-FP005-LINUX.tar, execute these commands:

# The profile used when installing ICN 2.0.3, if you use the CPIT installer it should already be correct
export profilePath=/opt/IBM/cpit/install-scripts/profiles/NexusConfig
# The path of the IBM Content Navigator Configuration and Deployment Tool, if you used the default location to install ICN, that should be correct
export configmgr_cl=/opt/IBM/ECMClient/configure/configmgr_cl
# WebSphere profile path
export was=/opt/IBM/WebSphere/AppServer/profiles/AppSrv01
# WebSphere node
export wasNode=P8Node01
# WebSphere server
export wasServer=server1

mkdir icnfp
tar -xvf 2.0.3-ICN-FP005-LINUX.tar --directory=icnfp
cd icnfp
sed -i "s/LICENSE_ACCEPTED=false/LICENSE_ACCEPTED=true/g" ecmclient_silent_install.txt
./IBM_CONTENT_NAVIGATOR-2.0.3.5-FP005-LINUX.bin -f ecmclient_silent_install.txt


$configmgr_cl execute -task configureicntask -profile $profilePath
$configmgr_cl execute -task rebuildear -profile $profilePath
$configmgr_cl execute -task deployapplication -profile $profilePath

# Delete cache and restart WAS
$was/bin/stopServer.sh $wasServer
rm -rf $was/temp/$wasNode/$wasServer/navigator
rm -rf $was/wstemp/*
$was/bin/startServer.sh $wasServer

It will ask you for your WebSphere administrator username and password when restarting WAS, you can also add the -username and -password options to fully automatize the upgrade

Make a MessageDialog larger

I’ve been really busy for the past three months but I’ll be writing again soon. Meanwhile, here is a quick tip that may be handy sometimes to make any MessageDialog larger, because default size is 350x275px, which is really not much if you have large information to display.

Use the following code just before calling the show function on your MessageDialog.

domClass.add(dialog.domNode, "largeMessageDialog");
dialog.show();

You will have to import dojo/dom-class as domClass of course.

And add the following code in your css file of your plugin:

.ecmBaseDialog.ecmMessageDialog.largeMessageDialog {
    height: 90%;
    width: 90%;
}

If you’re using this a lot, I would recommend creating a new dialog extending MessageDialog and putting this in the postCreate but that will do the trick for one dialog.

And last quick thing, if you want to pre-positioned/scrolled down the content at the bottom of the div because the bottom is more important (like success/failure…), you can just do this:

dialog.description.scrollTop = dialog.description.scrollHeight;

It has to be after the call to the show function:

dialog.show();
dialog.description.scrollTop = dialog.description.scrollHeight;

Deploy Jenkins on WebSphere 8.5

I’ve been struggling for a short time to deploy Jenkins on IBM WebSphere Application Server 8.5, so here is a few tips.

First, Jenkins needs Java EE 7 or newer, it won’t work on Java EE 6. The official help is located here.

The main step is to configure the class loader to load the parent last, for the module and the application.

Applications > WebSphere enterprise applications > application_name > Class loading and update detection > Classes loaded with local class loader first (parent last)
and
Applications > WebSphere enterprise applications > application_name > Manage modules > Jenkins v1.xxx > Classes loaded with local class loader first (parent last)

What the documentation does not say, is that there is a conflict with WAS 8.5 because Jenkins tries to configure the JSESSION cookie for the path /. Basically you will get the following error message:

Could not invoke an operation on object: WebSphere:name=ApplicationManager,process=server1,platform=proxy,node=P8Node01,version=8.5.0.0,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=P8Node01Cell,spec=1.0 because of an mbean exception: com.ibm.ws.exception.RuntimeWarning: com.ibm.ws.webcontainer.exception.WebAppNotLoadedException: Failed to load webapp: Failed to load webapp: SRVE8111E: The application, jenkins_war, is trying to modify a cookie which matches a pattern in the restricted programmatic session cookies list [domain=*, name=JSESSIONID, path=/].

To fix this, you can change the name of the cookie
Applications > WebSphere enterprise applications > application_name > Session management > Tick Override session management > Click Enable Cookies > Change cookie name JSESSIONID

You should also be able to remove the restriction in Global Security > Programmatic session cookie configuration but I haven’t tried that way.

Automated delivery of an ICN plug-in for continuous delivery

Agile is in vogue. Chances are good that your boss asked you to set up a build server to build your plug-ins and deliver them. At some point you’ll ask yourself, how do I automatically refresh the plugin on my environment, meaning without going to the ICN desktop and click the load button.

Here are 4 options, there might be more of course:

  1. Copy the jar and restart the whole web server (all of then if cluster). This reloads the plug-ins from their jars but that’s not conceivable for a production platform.
  2. Copy the jar and restart the ICN application on the web server. This also reloads the plug-ins. It’s better but still not conceivable for a production environment, we don;t want any interruption.
  3. Use Selenium and write a procedure to open the admin desktop, go to your plug-in, click the Load button and save. This is actually good, there is no interruption, just a bit boring to write and not easy to integrate to a build server (requires Selenium, running the browser…).
  4. Fake the behavior of going to the admin desktop and clicking load by calling the ICN rest api. This is what I’m going to develop here.

How does it work, the basics

Continue reading

Upgrade from ICN 2.0.3 to 2.0.3 FP4

Note: This post is superseded by its new version.

Here is a way to silently upgrade from IBM Content Navigator 2.0.3 to 2.0.3 FP4. You can use this right after using the CPIT installer to be up-to-date with your ICN version. You need at least ICN 2.0.3.0 to upgrade to ICN 2.0.3 FP4.

In the same folder you copied 2.0.3-ICN-FP004-LINUX.tar, execute these commands:

# The profile used when installing ICN 2.0.3, if you use the CPIT installer it should already be correct
export profilePath=/opt/IBM/cpit/install-scripts/profiles/NexusConfig
# The path of the IBM Content Navigator Configuration and Deployment Tool, if you used the default location to install ICN, that should be correct
export configmgr_cl=/opt/IBM/ECMClient/configure/configmgr_cl

mkdir icnfp
tar -xvf 2.0.3-ICN-FP004-LINUX.tar --directory=icnfp
cd icnfp
sed -i "s/LICENSE_ACCEPTED=false/LICENSE_ACCEPTED=true/g" ecmclient_silent_install.txt
./IBM_CONTENT_NAVIGATOR-2.0.3.4-FP004-LINUX.bin -f ecmclient_silent_install.txt

$configmgr_cl execute -task configureicntask -profile $profilePath
$configmgr_cl execute -task rebuildear -profile $profilePath
$configmgr_cl execute -task deployapplication -profile $profilePath