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!