How to debug your JavaScript in ICN

When you develop a plug-in, it is always nice to be able to debug, especially when you spent your day developing without testing, did hundreds of changes, and then got an error and there is no way to know where it comes from. We’ve seen in another post how to activate debug on the server side. Let’s see in this one how to debug the Javascript you have written.

There is two ways of doing that, a proper way fixing a Dojo defect, allowing us to see all files properly in the developer tool, or a temporary way which doesn’t require rebuilding and redeploying ICN. But I’ll tell you, after 3 weeks using the temporary way, I was almost crying and so relieved to find the right way to do that, so the temporary way is more for staging and GA platforms where you can’t apply the proper way.

The temporary way to do it

Because ICN is built on Dojo, it sometimes makes things hard to debug. Mostly because the Javascript files from the plug-in are loaded dynamically by Dojo. Hence you can’t see your files in the list of source files or when opening a file (Ctrl+P on Chrome) and cannot add breakpoints. A workaround is to use the two main files you always have, dojo/dojo.js and ecm/ecm.js and start from there by placing a breakpoint. The hard part is to know where to place it because there are both thousands of lines.

Debug an action

To debug an action you just wrote, you can place your first breakpoint in the ecm.js file, on line 28449, it looks like that:

ICN_debug_client

Then when it stops on it, just do F11 > shift+F11 > F11 to skip the getEnclosingWidget function, and you should end up in your own Javascript file. It will be a temporary file named VMXXXX like on my screen shot. Then navigator with F10/F11/Shift+F11 into your code. You can place breakpoints, the files will stay open and breakpoints will stay active until you reload the page, which you will have to do eventually if you modify your code.

I am warning you, since the file are really big, it’s really slow and after a while it could drive you crazy 🙂

The proper and permanent way to do it

This way needs more time to set it up. However, once it’s done, it really eases developments and make everything quicker. I would recommend using this way if you can take one hour of your time to make the following action (actually the server will be working for you, It just requires a few minutes of your time).

The problem is that the version of Dojo embedded in ICN has a bug (fixed in newer release) and it needs be fixed. It will allows us to open any file in the plug-in right from the developer tools.

To make it work, you need to edit the line 136 of the dojo.js.jgz file from the navigator web application.

var eval_ = new Function("return eval(arguments[0]);");
req.eval = function (text, hint) {
    return eval_(text + "\r\n////@ sourceURL=" + hint);
};

Let’s see together how to do that.

Backup the current ear

Start by backuping the current deployed ear, we never know what could happen.

move /opt/IBM/ECMClient/configure/deploy/navigatorEar.ear /opt/IBM/ECMClient/configure/deploy/navigatorEar_original_dojo.ear

Uncompress dojo.js.jgz

Start by locating the exploded sources of the IBM Content Navigator web application on the server. It usually is in:

/opt/IBM/ECMClient/configure/explodedformat/

Go into the following folder, this is where the dojo sources are:

/opt/IBM/ECMClient/configure/explodedformat/navigator/dojo

Uncompress the file called dojo.js.jgz, by using the following command or an utility like 7-zip:

gzip -d < dojo.js.jgz > dojofull.js

Backup the original gzipped file:

move dojo.js.jgz dojo_original.js.jgz

Modify the dojo file

In the file dojofull.js you just uncompressed, replace the line 136:

return eval_(text + "\r\n////@ sourceURL=" + hint);

with

return eval_(text + "\r\n//# sourceURL=" + hint);

Recompress the jar

Compress the dojofull.js file back, using the following command or an utility like 7-zip (using gzip compression):

gzip < dojofull.js > dojo.js.jgz

Rebuild the ear file

Now that we modified dojo to fix the issue, we need to rebuild the application. We will do that with the tool IBM Content Navigator Configuration and Deployment Tool.

Launch it with the following command:

/opt/IBM/ECMClient/configure/configmgr

Choose Modify an existing profile, and select your profile. If you did a CPIT installation, it is located in:

ICN_debug_client_dojo3

Then click Finish.

ICN_debug_client_dojo4

Then you have to re edit the profile configuration to re enter the WebSphere password. To do that right click on the main node, and click Edit Profile Properties…

ICN_debug_client_dojo6

Then re enter the password and save:

ICN_debug_client_dojo7

Open the Build the Web Application task and Run it:

ICN_debug_client_dojo5

Redeploy IBM Content Navigator

Now the last step is to redeploy the ear. Open the Deploy the Web Application task, and run it:

ICN_debug_client_dojo9

And that’s it, reload ICN in your browser. You should now be able to see any files when using the Open action (Ctrl + P in Chrome developer tool), like on the screen shot below, and files will open with their real names. And the awesome thing is that it will finally keep all your beakpoints between reloading pages!

ICN_debug_client_dojo10

 

2 thoughts on “How to debug your JavaScript in ICN

  1. Guillaume Post author

    Hi Gary,

    Unfortunately the debug option only sends the uncompressed version of the file. Chrome and Firefox developer tools decompress the files anyway, you will just get the comment that you don’t have without the debug option. But the worst is that when using the option you get only the ecm.js file, not the gzip version with everything in it, and you loose access to the source of all the JavaScript model and get only the css… Maybe I missed something though…

    Last but not least, it does not give you access to all the JavaScript of your plug-in (try searching the file with Ctrl+P that won’t work), and that was the purpose of this post. So my opinion is that except slowing down a lot ICN, the debug option doesn’t do much, and is even worst than good.

    Of course if there is more in this option I would be happy to know about it!

    Reply

Leave a Reply