A few Years of XPage Developement – Part 5

Fixing River – opentNTF Domino API

Introducing “openNTF Domino API”

This jewel has been created by a few wonderful developers with tier 5 status, XPage God.  (Yes, I skipped Tier 4 for now).  Developers with XPage God status are those that can create content that no developer can live without.  That content can be pure backend, controls, or both.  Up until now, I have only scratched the surface of what this beast can do.  Its main draw for me was that recycling is a thing of the past.  This was something that should have been done a long time ago by IBM itself.  If we do not have to clean up our objects in Lotusscript, why should we have to do so in Java?  But that is only the first of many improvements.  Iterating through documents in a DocumentCollection has become much simpler.  No longer must you use a while loop that quickly turns into an infinite loop that eventually crashes the HTTP task of the server.  Additionally, error handling is improved.  When an error occurs, the information is saved in files on the server, and if an openLog database is located on the server, the error information is saved there too.  No longer must you play with the NotesException class (a horrible invention to say the least, being the only Exception that I know of where the “getMessage()” method always returns null and that introduced the .Text public property).  The uses for this API are too many to list here.

Since the openNTF Domino API, or ODA as I like to call it, is so important, I have since made it a requirement for hxu version 3.  I have also updated all of my internal databases to incorporate that API.  Once I figured out how to get started with it, using the API is the simplest thing to do.  The methods are almost the same as the IBM Domino API.  The biggest advantages, however, are what to do if you have an issue.  The people who wrote the API are active members of StackOverflow.  If something does not work, you are unsure how to get started, or you get some strange error, write to the original authors via those forums, openNTF, or directly and get help.   Ask for such service from IBM, I dare you.

Future Outlooks

This brings us to the current day and the advent of a Tier 4 XPage developer, “Xpage Sith Lord”.  To Understand Lord status, let’s take a look at the current problem produced by all of my internal databases.  So far, I have about 6 internal active XPage applications.  This is not including development and QA copies.  Each of these applications relies on the hxu jar.  Furthermore, key properties are stored in a file under Resources/Files in the database itself.  Certain controls and libraries are being copied into each database instance.  When hxu changes, all applications implementing hxu must be changed individually.  This is starting to become a bit of a hassle.  Those with Lord Status no longer write stuff for a single database, but rather create OSGI plug-ins that can be easily installed on the server level affecting all applications which have those marked as required.  Controls and libraries need no longer be copied and pasted into new projects, properties can be saved in the xsp.properties file or in the domino notes.ini, and everything can be centrally controlled.  I have a long way to go before I can say that I have reached tier 4, but I can say that I recognize the next steps in my progress as a Notes XPage developer.

Tagged , , , , , , , , , , . Bookmark the permalink.

About reederProgramming

I already have an about me page, so I will just put a quick bit of info here. I am a Notes/Domino developer at holistic-net GmbH located in Hannover, Germany. I use Java primarily at home and as often as I can at work. I have dabbled in C# and a few other languages and platforms. This website started out as a place for me to quickly store and access some of my most important how-tos and has started to become a place where I can really help others too!

2 Responses to A few Years of XPage Developement – Part 5

  1. reederProgramming says:

    This is more or less the approach that I am using for now. My point with moving up to OSGI is that I see that as the more powerful option, and the easiest to maintain in a customer environment. I am just having a great deal of trouble getting started. I am not sure if my problems lie on the fact that I have never really worked with OSGI before, that I am not a domino administrator and perhaps am missing some security setting on the local server, or what ever else might be up. At any rate, although I can use the “tell http osgi ss” command to see that the feature is installed on the server, it is very obviously not on designer. It also does not matter how I try to install it. I have a fairly new StackOverflow open regarding these issues. When I finally have it figured out, I will definitely have to write about it.

  2. David Leedy says:

    There is another option for sharing Java code between different XPages databases then the OSGI plugin.

    What I did was I created a new template/database just for my Java code. Then I copied and pasted it into any application that needed it and told it to inherit design changes. So if I’m in a “contacts” app or whatever that uses the classes and it needs a java change, I do the changes in the Java Resources app and just refresh the design of the contacts template. That pulls in the latest Java code. This works very well if you can’t get to OSGI yet but keep in mind that more often then not you’ll need to restart the http task to see updates to managed beans.

    OSGI is still the MUCH better way to go but using design refresh isn’t that bad. And probably a little quicker overall for testing and stuff.

Leave a Reply

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