XPage Java dev Tutorial 2 – AdminPanel prt 1


 

General Feels and Gratitude

Hello Everybody!!  Today I am really happy to present my first NotesIn9 video!  It was really great being able to make this sub-series and be a part of the tutorials that really got me going with XPage development.  I want to thank David Leedy for giving me the opportunity as well as thank my employer for allowing me to use what I learn on company time to create content for others.  This is turning out to be a hobby that is really starting to take off.  Again, I have to thank twitter, David Leedy, and Paul Withers for sharing my first blog posts and spreading the word that this blog is out and about.  I would not be so into this right now if it were not for the fresh feeling of being able to do good for others and not just use this website as my own knowledge repository. Thank you to those who read these posts, watch the videos, and of course who retweet, comment and like what I am doing.  All that really makes it easier to stay motivated.


 

Down to Business

What is this mini/sub -series all about?

As you may or may not be aware, everything that we are doing here has a basis in my day to day development.  I started out using java for my xpage dev about a year ago (I had already used java extensively in my daily programming, just not in combination with XPages for which I mostly relied on JavaScript.) To really get started with Java, I decided to make a utility package that included everything that I needed to know to really get going.  I started off with making a sessionHelper.  I did this because I needed to learn how to get a session object.  I did not know anything about the variable resolver at first, and I also had a lot of trouble finding resources to figure it out.  After I managed that, I moved on to one of the most important features of all databases that I develop, the Admin Panel.

The Admin Panel is (currently) a custom control where I store tables that show the variable names and values of all objects located in the applicationScope, the sessionScope, and the viewScope.  I do not waste my time with the requestScope, although I suspect that such a thing would be possible if I found a use case for it.  Additionally to this, I show another HTML table that presents cookie information.  This is a part of another module that I call “the cookie helper”.  Finally, a larger and more complex table presents logging information to the user with a particular role.  The custom control contains functions that erase the variables located in the scoped maps (although I have not made that work without causing errors) add string variables to the scopes (not very helpful, but cool), and delete logging information shown in the debug section of the admin panel.  A great feature of the debug table is that there are six different error levels that all use different row styles.  This allows the trace information to be shown in a more understated way, and fatal errors to pop out like a sore thumb.  Later, I turned this same functionality around to store and show entire session logging documents in a logging database.

Today we are going to look at how to build your own Admin Panel using information built, retained, and retrieved in Java.

How is this sub-series built?

Due to time, I broke this down into three different parts.  Since I am actually coding on camera as much as possible, it is taking a while to get through it.  I am doing this so that you can see where I have difficulty, so that you can hear me commenting as I go, and because my entire concept in this Java Tutorial is to program an application from start to finish together.  When it is just taking too long and when I do not have a lot to say, I do edit out some parts.

Part one (this part) is going to be a basic introduction.  We do, for this one time only, go through a PowerPoint presentation where I go into what we are doing, the three parts, and some basic information about myself.  One thing that changed from the making of the PowerPoint slides to the videos is that the concept had to be changed from asking question before the recording of the next part to all the questions being asked in comments and through email and me answering them in a written format or in a fourth video.  It makes sense for numerous reasons, but we do not need to get into that.

Part two is primarily Java construction.  Although some Java classes were started in the first part, in part two we really get going.  I do not want to spoil it too much here, but we basically finish up all the beans that we are going to need for the custom control.

Part three is being my slight PITA.  I recorded it once already, but am not pleased with how it turned out.  I really need to stop doing my recordings after 1 AM.  I am going to be deleting the changes and redoing the video.  Part three includes registering the beans that we already made with the faces-config.xml file and designing our custom control.  We go into how to add a few custom properties, although we admittedly do not go into every detail that you could possibly go over.  There are numerous NotesIn9s if you need help specifically with Custom Controls.

 Why is this a sub-series?

This is a sub-series because it is a small part in the project that we are building together.  I was trying to find some way to make videos for this page’s main tutorial while also making content for NotesIn9.  I decided that it would be awesome to make some of the content that can really stand alone its own sub series and give them to David Leedy.  For those who follow along here, it should seem pretty seamless.  To those who watch the NotesIn9s, it is my hope that you can watch that content and get what you need without too much knowledge of what we are doing in the rest of the tutorials.  At any rate, I am posting the code on this website.  That being said, without any further ado- I give you the video, and following the video, the code!  Enjoy!


Video

Find the video here!


Code

COMING SOON!

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!