A few Years of XPage Developement – Part 2

Solar – Customer Project 1

Customer project 1, nicknamed Solar, was a solid tier 2 project.  We can refer to tier 2 as “Jedi Knight” level.  As a “Jedi Knight”, the programmer will use not only controls, but will also write some JavaScript code.

Solar was a very large project.  It was to serve as a single entry point for many other databases which all used the same design template.  Beware of the false sense of implied simplicity one could extrapolate from the phrase “same design template”.  Due to the configurable nature of the source databases, the individual source databases were as different from each other as the planets in the solar system, hence the project name.  Style sheets and a bit of JavaScript can change the style class name of a control, but this was configurability to an extreme. It included views created by script, language configuration, keyword configuration, configurations for configurations, too many for a Jedi Knight developer.  But let’s dive into the problems, take a look at what tools were available, and the details of the Solar experience.

Solar was built on Domino 8.5.3 and an appropriate version of the Extension Libraries.  The Extension Library was available for a little while, yet still in its infancy.  Many controls either did not work properly, and some did not work at all.  As is seen even today, if you want to build an application using XPages without the Extension Libraries, most of the controls and functionality that a customer and end user take for granted are not available.  Dialogs that are not self-implemented are not available; there are no value picker dialogs, no name pickers, or “advanced” controls.  Every view shown in an XPage basically needs to be constructed in the XPage using the View Panel or DataTable controls, and in many cases, those XPages must be updated if the background view changes.  There is no “one size fits all” approach.  XPage development without the Extension libraries?!?  NO THANK YOU!

Besides the ever present absence of what Classic Notes developers will call “standard controls” in the IBM installation, there were many other hurdles to overcome.  The most hindering of them was lack of developer help material.  Everyone was new to XPages and a good centralized help center did not exist.  The Designer help was no help at all, pun intended, and there was no home forum for designers.  Of course there were websites out there that to this day offer a place for people to ask questions and get help if they need it; however, unlike the current StackOverflow forums, you were lucky if your question ever received an answer and if it did, it almost never helped.  Being the first of the company to take the plunge into XPages, there was no person locally who could take a look at code and tell me what I was doing wrong.  Partner companies rarely had it better.  The developer was on his own in the early day of XPages.  There was no Designer based Help application, no good forums, no fellow developers, no real documentation of the basic IBM libraries or the extension libraries, and very little more than demonstration databases provided by IBM (Team Room template) and openNTF (numerous applications delivered with the ExtLibs).  The problems of figuring out what to use and when to use them were only the tip of the problems back then.

The more interesting problems happened when you did not know what the problem was, only the symptom.  This is a problem that exists to a point even today, but not nearly as bad.  Domino 8.5 did not come with a debugging option for JavaScript.  This was a nightmare and a big reason why I refuse to develop XPage applications for any server below Domino 9.  I will not do it.  (Truth be told, if the boss says do it, you do it….)  Not having a debugger is one issue in and of itself, but it is made much worse with the implementation of the JavaScript coding windows of the IDE.  When you write JavaScript code in designer, it is only slightly better than writing the code in notepad.  Certain errors could and should be found.  For this, let’s look at an example.  If you want to test that apple equals oranges then do something with pears, the code should look like this:

if (apples == oranges){  pears.doSomething();}

but you write:

if(apples = oranges){ pears.doSomething();}

a very strange thing happens.  First off, this error WILL NEVER BE FOUND AUTOMATICALLY. It will not be spit out as an error during run time, or at design time.  It will simply and quietly replace the value of apples with the value of oranges.  This sort of mistake, which can happen unbelievably quickly when trying to type functions in a semi quick way, can cost hours if not days of searching when you do not know that it happened and can just see that the result of the function is wrong, if you notice in the first place.  Without debugging functionality, you can kiss your week goodbye.  The only option you really have is to spit out values to the server console and hope you eventually find it, or have a bunch of interns read your pages and pages of code to see if they find anything.

If that was not enough, when you create a SSJS library, all un-nested functions and variables are written on the left side panel.  This is the same functionality as seen when writing a Lotusscript library and is nothing new.  One huge disadvantage is that these variables are not sorted alphabetically, but rather in the order in which they are in the file.  This is highly annoying.  During development, the developer must write the code in alphabetical order or risk not finding the functions later.

Because of these limitation, the Solar project ended up taking roughly four times longer than planned, and even was in danger of reaching or exceeding a year of development time.  At that point, I did not want to touch another XPage project as long as I lived.  I was frustrated, angry, and dumbfounded.  IBM had sold something as “easy” and “quick” and “the future” and all I wanted to do was bury it outside next to Spot the cat.  We had seen that it was not easy, it was not quick, it was expensive for the customer, and if it was to have any future at all, things would have to change dramatically in the next version of Domino.

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!
Tagged , , , , . Bookmark the permalink.

Leave a Reply

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