Enter the OSGi – Cool shit is on the way

holistic-net has a bunch of little projects/products, all of which has something to do with IBM Connections – a sort of business social website for either intra- or internet.  Greenhouse is a good example of it.  In order to bunch our products and services which do something with Connections, we are looking into transferring those products/projects into a completely modular java project.  The framework of choice — Eclipse 4.

I am new to eclipse and OSGi development, even though I started to dabble in extending the XPage runtime with OSGi, I am not ashamed to admit that I was not sure what I was doing… Those of you on stack overflow more than likely know that I have asked many questions regarding OSGi dev and I have not been overly successful.  I am ashamed to admit that I did not first look into how eclipse development really works and decided instead to jump off the deep end and somehow expect it all to work.  Lesson learned.

Come to think of it, I learned a great deal in the past two weeks.  So much so that I am about to burst.  Moreover, today is one of those days that shows why I want to be a programmer, why I love my job, and why I cannot imagine doing anything else.  In the past two weeks I was frustrated with example projects, fearful that I will not be able to learn the concepts and get things going, and perhaps a bit down on myself.  Today was the pivotal moment when it all went click and I can say that I am not only happy with what I have accomplished, but I am also seeing the full power of the eclipse framework.  Even more than that, I think I can take what I learned with plug in management and organization and move it into all of my future project development.  (Although that is more than likely just personal preference stuff anyway)

Ok, so none of this is making much sense to “normal” people so I guess I better explain myself.

1. Separation of UI development and data management.
What I mean by this is that all you need is a data model.  This model is best in an Interface.  Aside from this, you can have a service model interface.  These two interfaces are then used to build the UI.  Actually, what I have been doing is using the model interface to build a jface bean.  There seems to be a bit more to it than building a Bean for XPages, but not too much more.  In fact, it is pretty easy when it comes down to it.  Just build an abstract bean model and then just extend it and add a bit more code into your setX methods.  This allows the GUI to not care at all where and how it is getting its data.  It only wants it to follow the interface that is located in the model plug-in.  This allows for easier GUI testing, and the gui does not have to be updated if the Data Services change.

2. Modular Design
Imagine you have two brothers.  Both of them are going to use the same budgeting software programs that you design.  Brother one, lets call David, is not too bad with computers, has no fear of it, and can follow your install directions, even if they are a bit more complex.  For him, you want to use your default design of saving information into a database.  This is the easiest way to keep track of and query your data, so why not.  You can deliver the project easily to him with the data service plug-ins necessary for JPA data persistence.  And since your data is saved in a model, you can use the service Interface to verify that you are delivering the proper functions.  Now let’s say you have a second brother named Brian.  We can admit that he is a bit of a douche and does not like fancy stuff.  He likes his toys to be slow and if he can make you run around the block a few times, he will gladly go inside, get a lawn chair and a lemonade, and he will watch you jump through hoops on that blistery summer afternoon.  You can build another service that follows the model service interface and it will handle the data the way Brian needs.  Later, when John comes along, he can decide if he wants to be a Brian or a David, you still have both service implementations and he can decide which he wants to use.

We can even take this a step further and not limit it to our annoying brothers.  We can also look at pure content.  We have an application and we want to define different roles to it.  The first role is purely user input and basic displays.  He can have an instance installed onto his computer containing the plug-ins that allow him to most efficiently perform his task.  The second role is more of an administrator.  He needs to be able to do everything that first role can do, plus this user needs to be able to perform administrative tasks and needs advanced perspectives to handle those tasks.  His instance of the application will include those plug-ins all of which extend the base UI.

3. Styling controlled through CSS
Actually, I am not sure whether or not this was an option in normal SWING UI development.  I do not think so.  Anyway it makes customizing the front end very easy.  I do not know too much about this yet, but I see it as a cool ability.

4. Event Driven application with contexts and a lot of cool shit like injection
The framework takes care of all of your application needs.  Set an object into the context and be done with it.  If the object is configured to be available, the framework will also inject it into your methods and you do not have to worry much.  (You need to be smart, but still)  This eliminates the need for a single factory class or program class that maintains critical program data. There is so much candy that I would have to write a book to get into it all.  I suggest you try it yourself.

 

This means that cool stuff is going to be done with BudgIt, or well MoneySucks as I have now started to call it.  I will be transferring everything into an Eclipse 4 application.  I am excited and cannot wait to get started.  Come to think of it, I might as well start downloading eclipse right now!

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.