In this post, I will describe how to embed and use a Java applet in your IBM Content Navigator plugin. Applets may be useful to overstep some JavaScript limitations, usually related to security, for instance read/write the client’s file system.
I won’t explain how to write, package and sign your applet since you can find plenty of tutorials on this topic on the web. However I will explain how to embed your applet into your plugin, then how to use it.
Continue reading
I really had to write one single article about all issues occurring when using Workplace XT Entry Template in ICN, because at the time it wasn’t as clear as now in my mind. There are actually two main different issues (in some ways related) both concerning the Entry Templates in ICN, both because they are Workplace XT Entry Templates.
Therefore I am going to split them in two different issues, in two different threads:
This is the second post about the issue occurring when using Workplact XT entry template with ICN. We’ve seen that there is an inheritance problem in this post, we will now see that there is a problem of File Types filters. This issue needs to be addressed if you want to use the second work around of the former issue.
You’ve created Entry Templates in Workplace XT, and also created a few File Type Categories gathering several MIME Types. You’ve used these Entry Templates by associating them on a folder to use them when adding document. You restricted them by File Type Category. For example ET 1 is only for Images (File Type Images gathering image/png, image/jpeg, …), ET 2 is only for office documents, and ET3 is for every king of document. That looks a little bit like that in Workplace XT:
Problem is that in ICN, this does not work. You always get the generic entry template (in my case misc doc, or no Entry Template if they all have restrictions on the File Type Categories.
Continue reading
I just noticed that the following function is not working as the documentation says in the ICN JavaScript model. Actually it can not be used with a document path.
retrieveItem(itemIdOrPath, itemRetrievedCallback, templateID, version, vsId, objectStoreId, action)
Sources for the server part of ICN are not available. However it contains code for all public API services you are using in the ICN JavaScript model, like retrieve an item, a folder content, check in or check out an item and so on. And sometimes it is nice to know what is going on in these services, which can’t be debugged. A way to do that is to set the log level on DEBUG for the ICN server. Of course never do that on production…
This is actually really easy, you don’t even have to do it using Websphere, just go to the administration of ICN, Settings, Logging tab and set the Application-level logging to DEBUG. You can even define what classes/packages you want to log. Then restart WebSphere (maybe restarting the navigator application should be enough I haven’t tried) and you should have all debugs log in the SystemOut.log file of WebSphere (/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1). That’s might be a lot so don’t forget to filter on some classes/packages.
Continue reading
Sometimes you need to use an external JavaScript libraries in your plugin, because you don’t want to reinvent the wheel. Problem is that often those libraries are not Dojo modules. So how to use them in your dojo class?
Well that’s simple, dojo provides an generic script injection mechanism. Everything declared in the external script will be available in your class. Code is the following:
require(["http://host.com/stuff.js"], function(){
// Everything declared in stuff.js is available here
});
You can link to an http location, or relative location into your project, for instance /application/stuff.js.
Now how to use that in your plugin? You can place your JavaScript file in another application or a CDN to refer it with an http protocole, example:
require(["http://host.com/application/stuff.js"], function(){
// Everything declared in stuff.js is available here
});
Or you can leave the file in your plugin so everything is embedded when you deploy:
require(["plugin/MyPluginID/getResource/jszip/zip.js"], function () {
// Here I can use the variable zip
});
I really wanted to write this because I had some hard time figuring out how this works. The documentation is just wrong and I had to debug quite deeply ICN to understand what the problem was. The function to add a folder is:
Be careful with the Entry Template, they can have two states, retrieved or not retrieved. They contain a lot less information when they are not retrieved.
Here is how to check if it’s retrieved or not, and retrieve it if you need to:
if (!entryTemplate.isRetrieved) {
// Retrieve it
entryTemplate.retrieveEntryTemplate(lang.hitch(this, function (retrievedEntryTemplate) {
// Do something with retrievedEntryTemplate
}), false, true);
}
Here is the JSDoc of the ecm.model.EntryTemplate class, and the one of the retrieveEntryTemplate function. Actually the entry template object itself is updated so most of the time you won’t have to do anything in the callback except wait for it to happen. Example (function converting to classic callback to promise):
Continue reading
repository.retrieveItem(documentOrFolderId, function (contentItem) {
// Do something with the ContentItem
});
repository.retrieveItem(folderPath, function (contentItem) {
// Do something with the ContentItem
});
Note: Unlike the documentation says, that does not work with an document path (see this), only with a folder path. However that works with both Document and Folder ID.
Example:
repository.retrieveItem(item.id, function (contentItem) {
// Do something with the ContentItem
});
repository.retrieveItem('/Folder/MySubFolder', function (contentItem) {
// Do something with the ContentItem
});
var contentClass = repository.getContentClass(string id);
JSDOC. Example :
var documentClass= repository.getContentClass('document');
var contentClass = doc.getContentClass();