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