Towards the end of last year we were asked about undertaking a Notes client plug-in development project. At the time my plug-in development experience was zero. Apart from a brief look at the source code of the Extension Library source code, my only other Eclipse experience was from about six years ago using the XML editors. And the sum total of my Java experience was four hours in evening classes about six years ago, that brief investigation of the XPages Extension Library and about two years experience of Server-Side JavaScript. I know that SSJS is not Java, but I list that in my experience because I strongly believe it helps bridge the chasm between LotusScript and Java. It’s still a rather shaky, rope-bridge (there are still quite a few aspects of Java development that are not broached when undertaking SSJS development), but it allows developers to become more familiar with the differing syntax, the methods for error handling etc.

 So all-in-all I don’t think I was that much further ahead of other Domino developers.

 So why did I consider taking this leap into the unknown? Firstly, plug-in development offers the potential for significant enhancements to the Rich Client Platform experience, the kinds of potential that just wasn’t there prior to R8. You just have to look at what’s available in things like File Navigator and Wildfire, both winners of Lotus Awards for open source contributions. Even still, it’s currently a relatively niche area not exploited as much as it could be to add value to users’ experiences in the Rich Client Platform. That’s probably because it was not until 8.5.1 that Java UI APIs were available, finally allowing plug-ins (as well as Java agents) to interact with the Notes UI and, consequently, Domino applications. (That this was missing prior to 8.5.1 will probably come as a huge surprise to Domino developers who have never done Java and a further affirmation that LotusScript is king for the client.) But the inclusion of Java UI APIs extends the functionality that can be surfaced in plug-ins. And looking to the future, there are likely to be performance enhancements to XPages in the Notes Client in 8.5.3. Factor in plug-in development as well, and you have a clear reason for using XPages in the Notes Client over a browser.

There are also a number of open source plug-ins available, which provide a method for would-be plug-in developers to get up to speed. Along with books, they allowed me to gain enough of an understanding of Java to supplement my knowledge of the Domino Object Model to build functioning Java code. Yes, there are differences between plug-in development for various releases of Notes and that needs to be borne in mind. But it makes it more accessible. Beyond plug-ins, the XPages extension library provides some useful information for configuring Eclipse to work with Domino and that documentation was invaluable. Also, at the time I was considering the project, the redbook wiki on plug-in development was being finalised. It didn’t come out until after the bulk of my work was done, but it is another learning resource. And of course there area a variety of learning resources available on the Eclipse plugin development site. This all meant I was able to investigate, deconstruct the requirements into manageable steps and have enough confidence that it was feasible for me to successfully deliver a solution.

But I also had reasons beyond plug-in development for wanting to gain experience in this field. I am always looking to transfer skills gained in one area, as I was by transferring my experience of LotusScript and Server-Side JavaScript to plug-in development. Skills gained from the LotusScript editor (like Ctrl + click on an object or highlighting an object and pressing F3 to navigate around your code) and XPages source editor (Compare With > Local History) made the Java editor in Eclipse seem familiar. Equally I want to port the experience I gained on Java from plug-in development to using Java for building my own XPages extensions and for writing Java within XPages. In comparison with the LotusScript editor and Java editor, the SSJS editor feels rather inadequate. Factor in difficulty of debugging or good error management* and Java becomes a rather attractive proposition, particularly bearing in mind it performs better.

So with all of this in mind, this was an attractive project and one which has proved, at least so far, successful. Not only was it successful in terms of being able to achieve the goals for the plug-in itself, it has been successful in terms of enhancing my skill-set in preparation for future challenges. Yes, there was a learning curve, but no more challenging than the jump from traditional Domino development to XPages. Yes, there is going to be more learning required for using Java in XPages (managing data types, accessing the current document etc.). But, again, the experienced gained should make that step easier.

 If you don’t already use it, the OpenLogXPages script library in TaskJam is invaluable for error management. Nonetheless, many SSJS errors do not identify the line number it occurs on. Some make it difficult to understand the exact cause. The absence of code templating in SSJS makes it laborious to add try…catch blocks. And the kind of stack trace we’re blessed with in OpenLog in LotusScript, which allows you to quickly and easily track through the various functions and design elements touched by the process, is unfortunately missing in SSJS at the moment.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.