And the gloves are off……

Picture this: I have been away for 5 days and during that time “someone” has been posting cryptic comments on twitter about how the next notesin9 is going to be different….and scaring me.

So I am waiting at the airport this afternoon, about to board my plane home and I get this link from this “friend” who tells me to watch the new video it and enjoy. I download it and watch it on the plane. People start to look at me funny as I start to snort and giggle at my phone.

I am sitting here are 30,000 feet laughing my ass off at the video. Not only at the brutal use of apparently free Child labor, the amazing feminine  likeness of my voice and the awesome lip synching 🙂

The video is of course the latest notesin9 episode 141 and for the record Dave is smarter than he let’s on!

Dave is a good friend and I metaphorically love him to bits – I loved the episode – loved the fact that he took so much time to create it – love the creativity – love the humor / love love love. Thank you I am very flattered.

The gloves are off is a reference I get, something to do with Canadians and this guy called Neal who plays for the Penguins…..I dunno…anyway….

Dave’s overall point is right, horses for courses, the right language for the job and the right job for the customer.

He is right that front end and back end  are 50% equal in importance. The end user doesn’t care about back end and it has 0% importance to them. Your IT manager cares nearly 100% about the back end code and making it maintainable. Who is your customer? 😉

This healthy discussion will go on forever apparently and only serves to demonstrate how complex XPages can be. To IBM’s credit they have created a technology which is equally at home as:

The original and arguably still best secure NoSQL data store who’s primary task is serving JSON to a JavaScript framework such as Angular or backbone

An interoperable, integration platform which provides an application building capabilities with simple drag and drop data controls and a powerful back end data parsing capabilities.

and everything in between.

Love ya Dave 🙂 thanks for the laugh.

I can’t wait to get off the plane and see everyone else’s reaction 🙂

Next time we have a beer I’ll point out the significant errors in your video 😉

When the community comes together we get the right answer

Last week I posted why JavaScript is more critical a skill to learn than Java. There was an outpouring of comments, discussion and responses unlike any I have seen in a while.

To give a little more background as to why I decided to post: I was not to be antagonistic or instigate a storm in a tea cup. It was because for the third time in 2014 I had been told by a notes developer something along the lines of “I can’t learn XPages because I have read that you need to learn Java and I do not have the time/skill to do so”.

For right or wrong the perception gleaned from community blogging was that was Java was required learning, which is not the case. And so I blogged.

What I did not forsee was the outpouring and wealth of knowledge bestowed on my blog comments by more that 20 members of the XPages community. I believe what was created was much much better than the original post alone and is one of the best examples of the community working together to get the *right* information out there.

The comments are unfortunately not the easiest thing to follow as there are so many of them (which is great) so what I will be doing in the near future is putting together a compilation of the sentient parts of the conversation ( ignoring the pointless sarcasm) as a resource for all.

In the mean time I wanted to say thank you one an all who contributed and to let you know I got so much more out of the post then I ever hoped for.

Thanks !!!

Why learning JavaScript is more critical to XPage developers than Java

I have tried to write this article multiple times over the last 2 years, when I read it back to myself it always sounds like I am bitching. Honestly, I usually am and that is why it has not been published. This is a final attempt at a constructive argument against the insistence on many blogs that everyone should learn Java.

Many people think I hate Java; I really don’t. I can program Java (I am no expert admittedly) and have done so on multiple occasions. My concerns are always raised when community members are insistent that everyone should learn Java. I do not believe that to be the case.

Why I believe JavaScript skills are more important to a web developer using XPages than Java.

Since R4.5 Domino has been a web server – and the client side user experience has always been independent of that. The only decision to make them “tightly coupled” was that of the developer who chose to not venture beyond the bounds of the out of the box capabilities.

Just because no-one was championing client side development does not mean that it did not exist. I used IE5 <XML> islands back in 2003, pre-ajax, to make dynamic data loading views. I used jQuery in 2010, long before I experienced XPages. I have always considered myself a web developer. I am sure there are many others who do the same.

Here’s why a long long time ago one of my biggest projects failed. While it exceeded expectations of the customer and absolutely rocked on the server, the end users were never asked if they liked how it looked. It failed because people didn’t like the way it looked and it wasn’t used. It hurt. It really, really hurt. From that project forth I stopped putting the server first.

“Beginner XPage developers need to learn Java / Everyone should learn Java”

I shake my head every time I see this. It is an all out, complete, and utter fallacy. Below are my thoughts on some of the reasons touted for using Java and not SSJS:

  • Speed
    • On low to medium volume document processing the time saving still insignificant compared to network latency and browser rendering speed. I have no numbers on this but in over two years XPages developer and 4 major projects dealing with <50,000 documents in a database. Speed of response from the SSJS code on the server has never been a concern.
    • I recently worked on a database with over 1,000,000 records in it. Accessing and displaying data via SSJS using FTSearch was in the matter of 100s of milliseconds.
    • We have SSJS code getting view entries by key and returning results on 250,000 records in less than 0.5 seconds
    • As has been pointed out in the past, the server caches a large amount of frequently used SSJS code making it no slower than any Java equivalent
    • Java is faster – Yes it is. But in my experience SSJS seems perfectly fast enough.
  • n-tier architecture / Separation of  UI and business logic layers
    • When someone can demonstrate to be that they understand the UI they can lecture me about how they need to separate themselves from it. From my perspective it makes a back end developer’s life easier to separate themselves from the UI they don’t understand.
  • It’s the future
    • I guess that depends on your perspective. If you want to spend the rest of your development career developing WebSphere applications it might be. Either way it absolutely is not necessary for XPages development in the next 2 years
  • Java can do things SSJS can’t
    • Yes I agree, things like Apache POI, custom REST services or Plugin development – absolutely agree.
    • Complex data processing of significant amounts of data (not a normal use-case for a notes database)
    • Use the right tool for the right job 🙂
  • At this stage of the game anyone still resisting a move to XPages is not going to be encouraged by being told they need to learn Java – So please quantify your statements when you tell other community members “they must learn Java”. I think this is more appropriate – “Those of you with a solid understanding of XPages and the JSF lifecycle, who are wishing to take their server side programming skills to the next level, learn Java”
    Beginner XPage developers have enough to learn as it is 
  • Imagine a notes client developer who has never created a web based application before. Which is going to serve them better JavaScript or Java
    AJavaScript – the same language for CSJS and SSJS

I believe XPages web developers (using XPages) need to have a solid understanding of these technologies to be successful – *In this order*

  • Lotus Notes Object Model (assumed)
  • HTML
    • HTML5
  • JavaScript
    • Basic Programming
    • External Libraries (jQuery, dojo)
    • The XSP framework for CSJS JavaScript interaction with the XPages
    • Unique Browser deviations from the ECMA standards (looking at you old IE)
  • CSS
    • Unique browser deviations from the standards
  • XML
  • JSF Lifecycle
  • Other things I have forgetten
  • Java

In Summary: Why is JavaScript more critical to XPage developers than Java?

  • Coding in Java is not necessary to build a web based application (using XPages), JavaScript is.
  • Coding a web browser user interface requires JavaScript and cannot be done in Java
  • JavaScript skills are transferable to *any* web server/client environment, Java much less so.
  • Because no customer ever said “This website looks like crap but the pages load so fast I am in love with it.

I understand everyone has their talents in different areas, but (and I can’t stress this enough), end users don’t care about the technology that makes a website work. End users are more forgiving of a beautiful website which is slightly slow, that a blazing fast, ugly, hard to use site. Ideally it would be beautiful *and* blazing fast but that is a whole separate discussion.

I am not saying using Java is wrong. I just want to temper the expectation that everyone *needs* to learn Java. In my opinion they don’t.

Let the comments blaze on…..

Every time you use a 5 year old IBM XPages out of the box dojo control and tell a customer that it is a good interface, a kitten dies.
Many thanks to Brad Balassaitis for proof-reading and bitchiness reduction assistance 🙂

PATCHing a Document using Domino Data Service

Talk about frustrating – in a week full of slow progress and CORS cross domain hell I found this little annoyance after hours of staring and curing – once again the power of trial and error triumphs over my stupidity again.

The problem

I have a Domino Data Service running on the server and I want to update a document

This is the imaginary URL

returning the imaginary data just fine


and I am trying up to update it using a simple AJAX call

  data : {'marky':'newfields'},
  type: 'PATCH',	
  contentType: "application/json", 

Unfortunately I get this big old ugly error….
“text”:”Bad Request”,
“message”:”Error while parsing the JSON content”,
“data”:” Error while parsing the JSON content\r\n\tat\r\n\tat\r\n\tat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\r\n\tat sun.reflect.NativeMethodAccessorImpl.invoke(\r\n\tat sun.reflect.DelegatingMethodAccessorImpl.invoke(\r\n\tat java.lang.reflect.Method.invoke(\r\n\tat org.apache.wink.server.internal.handlers.InvokeMethodHandler.handleRequest(\r\n\tat

bunch – o – useless Java Stack Trace which never helped anyone…….\r\n\tat\r\nCaused by: Error when parsing JSON stream\r\n\tat\r\n\tat\r\n\t… 65 more\r\nCaused by: Encountered \” \”approved \”\” at line 1, column 1.\r\nWas expecting one of:\r\n \”false\” …\r\n \”null\” …\r\n \”true\” …\r\n <INTEGER_LITERAL> …\r\n <FLOATING_POINT_LITERAL> …\r\n <STRING_LITERAL> …\r\n \”{\” …\r\n \”[\” …\r\n \”(\” …\r\n \r\n\tat\r\n\tat\r\n\tat\r\n\tat\r\n\t… 66 more\r\n”

The solution

So I googled around and I found that the error is caused because the is expecting a string as input – once I found that the solution was simple – send a string and not an object…

  data : '{"marky":"newfields"}', // Notice this is now a string not an object
  type: 'PATCH',	
  contentType: "application/json", 

PATCHing of a document makes a lot of sense for many reasons – mostly because of reduction in bandwidth – the example code works nicely – but you have to update the web site document to allow the PATCH method.

Be aware that using code like this you are also exposing all your data to having any old fool like me breaking your field based workflow and filling your documents full of crap data if they so chose to.

My suggestion would be to use your own REST service written with your own protections in it 🙂

Once again my stupidity is boundless and as I already discovered on multiple occasions,  JSON is a string and not an object.



How to add icons to individual items in a Select2 multi-value field

Select2 is one of the best user interface enhancers I have come across – if you do not know what it is then you need to go play with it.

It transforms SELECT boxes into dynamic, stunning, interactive UI elements and allows for all sorts of customizations and developer fun.

What I want to be able to do is select items from different categories within the select2 box and then add an icon displaying to the user which category they came from. In this article I will show how.


I want to take this


turn it into this with a type aheads2

And when a user selects the items – make this based on the category selected


And it is really pretty simple and straightforward.

The Code

We start with our select box

<select style="width:500px" id="vehicle" multiple="multiple">
<optgroup label="Cars">
	<option class="car">Honda</option>
	<option class="car">Toyota</option>
	<option class="car">Ford</option>
	<option class="car">GM</option>
<optgroup label="Bikes">
	<option class="bike">Harley Davidson</option>
	<option class="bike">Kawasaki</option>
	<option class="bike">Aprilia</option>
	<option class="bike">Ducati</option>

and then we add our select2 code

$("#vehicle").select2().on("change", function(e) {
	if (e.added) {
		var icon = ""
		$('.select2-search-choice DIV').filter(function() {
		    icon = '<img src="images/'+e.added.css+'.png"/>&nbsp;';
		    return $(this).text() ==;

So what this does is:

  • select the #vehicle DOM element
  • turn it into a Select2 plugin control
  • When the control is changed and if an element is added
  • Find the DIV which has been created to display the new item
    • We use filter based on the newly to make sure we only get the one just created
  • create the HTML for the appropriate icon based on the class of the selected item
  • prepend that icon HTML inside of the DIV containing the newly selected option


I have barely scratched the surface of what is possible with Select2. But I hope that you can see with only 9 lines of code we have significantly improved a user experience 🙂

I love Select2 and the options are endless

Enjoy 🙂

My ongoing struggle with stupidity and what is not valid JSON

So this was a frustrating lesson to learn – and please feel free to be entertained by my apparent stupidity.

I was trying to create my own JSON with an xAgent – seems easy enough. I created a simple output which looked like this

    'items': [
            'name': 'AK',
            'dc': 23

and when I fed it through my AJAX code it failed.

	dataType: 'json',
	url: ""+query
	//url: ''

But what was interesting is that it returned the data (e) correctly. I was baffled and frustrated for way too long.

So I finally asked he correct question of google (isn’t that always the case) and I found that was telling me the strings were incorrect…..

because JSON requires double ” and not single ‘


This worked – changed the single to double quotes.

    "items": [
            "name": "AK",
            "dc": 23

and I am apparently now less stupid that I was yesterday…….


Kathy recommends –

jQuery in XPages #20 – NProgress – YouTube-like slim progress bar

In this article I will describe how to implement and use the jQuery NProgress nano scrollbar plugin


The XPages integration of NProgress is demonstrated here


The demonstration database can be downloaded from the link above or from here



Since added their nano scroll bar at the top of the page there have been a flurry of different jQuery plugins which mimic the nano progress bar at the top of the screen.


The silly thing is that the progress bar itself does nothing useful.

  • It does not
    • Indicate any meaningful progress on the download of the AJAX or page
    • Give any indication of the likelyhood of page download completion
  • It does
    • Give the user a false sense of something happening on the page
    • Provide a nice User Experience for very little overhead and effort on the part of the developer

Using NProgress you can very quickly and easily add this capability to your website for only a very small overhead to the size of your application.

Adding NProgress to your XPages

  • Go to the NProgress site and download the file from the github site linked on the page
  • Drag and drop the contents of the zip file into your WebContents folder
  • Create a sample page with the following
 <link href='nprogress/support/style.css' rel='stylesheet' />
  <link href='nprogress/nprogress.css' rel='stylesheet' />

	<xp:headTag tagName="script">
			<xp:parameter name="type" value="text/javascript" />
			<xp:parameter name="src" value="js/jquery.js" />

	<xp:headTag tagName="script">
			<xp:parameter name="type" value="text/javascript" />
			<xp:parameter name="src" value="nprogress/nprogress.js" />

The reason we add this to our XPage in the manner above is because nprogress uses AMD as a possible loader (to integrate with require.js) and because of that Dojo 1.8 (on an R9 server) breaks it.

On my demo page I have loaded a viewPanel with 1300 documents in it – I cannot show you more because I do not want a large database on my host’s site but rest assured if you run this up to a 5000 row viewPanel the effect is better because the refresh is slower.


On the demo I have included the main example from the NProgress site and you can see that there are a number of methods for starting and manipulating the progress bar. I use start because it very nicely randomly increments itself to give that illusion of progress.

On the XPage I have a button which refreshes the view Panel – and in the client script as the button is pushed I start the NProgress. In the onComplete of the refresh I end NProgress and really it is as simple as that

<xp:button value="Reload  viewPanel" id="button1" styleClass="clickMe btn btn-warning">
	<xp:eventHandler event="onclick" submit="true" refreshMode="partial" refreshId="viewwrapper"

I would suggest that if you are able to integrate with Tony McGuckin’s excellent XSnippet for intercepting dojo io events you could create an automated NProgress bar should you so chose.


As web developers we have used spinners in our application for quite a number of years – this is a new twist on that concept and seems to be getting very good reviews from users. Consider integrating it into your applications.