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.
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.