Why XPages should get Web Sockets

Web Sockets

Web Sockets is not “new” but it is, in the sense that it is an HTML5 standard which is not implemented yet in all browsers. For more information check out this excellent article on it. Written two years ago !!! And yet many people have not yet heard of it.


So what’s the big deal? We have web polling right now….

In a nutshell Web Sockets allows for an open connection to be maintained between the server and the client. Que? So what? I hear you say…

If you think about your twitter feed, facebook update feed or your Social information stream in Connections or Notes Social, the way it works is via a one way “polling” from the browser to the server – the conversation looks something like this via an ajax request

Browser: “Do I have anything new?”
Server: “Nope”
5 seconds goes by
Browser: “Do I have anything new?”
Server: “Nope”
5 seconds goes by
Browser: “Do I have anything new?”
Server: “Nope”
5 seconds goes by
Browser: “Do I have anything new?”
Server: “Nope”
5 seconds goes by
Browser: “Do I have anything new?”
Server: “Yes here is a new message”

What this does is create a huge amount of unnecessary bandwidth on the network – and just as importantly requires the server to maintain a ton of open threads at all times to allow for the constant polling – slowing down the server – all in it is a very expensive (but necessary) methods for getting “real-time updates” to the browser client. It also it (in shall we say less sophisticated browsers) causes a RAM increase and memory leaks – over time resulting in browser failure.

All change with Web Sockers

Web Sockets allows for an open connection – just as if your computer is on the LAN – traffic can flow both ways.

So there is no longer a need for “polling” in the same fashion.

Use Case example

If I had Web Sockets this would be the first demonstration I would do. it is directly applicable to our work environment and would :

User A

Creates an expense claim request and submits it to User B for approval.

On the server we are running a scheduled agent (or equivalent) which picks up the approval is required

User B

Logged into the intranet 3 hours ago and has not been into the expense system once.

Because she is logged into the system the supervisor has an open Web Sockets connection to the server.
The server “pushes” the new approval request to the supervisor’s browser without the need for polling and it pops up in her “stream” as a task which requires her action.

One HTTP transaction instead of many.

Other examples

Other tangible examples are :

  • Real time charting – updating your corporate stock ticker, but only when a change is necessary
  • A sidebar chat capability, changes pushed not polled
  • Web conferencing (with HTML5 audio and video tools)
  • Online games

Here’s what Jesse Gallagher told me: Having a “direct feed” between the client and backing objects on the server could lead to all sorts of interesting applications, even better than the remote services in the ExtLib


Web Sockets is a new technology, now supported in IE10 and will provide multiple advantages to the corporate infrastructure:

  1. Significantly reduced Web based LAN traffic due to the removal of “polling” from the browser
  2. Faster servers requiring less resources due to to the reduced traffic requests
  3. It will save money and resources
  4. It will provide for a faster browser – improving user experience.


Great conversation with Jesse Gallagher

This week I had the great pleasure of Co-Hosting the Taking notes Podcast with Bruce Elgort and JulieAnn Robichaux – http://www.takingnotespodcast.com/blogs/takingnotes.nsf/dx/TakingNotesEpisode171.htm. This week we were talking to Gigerby Jesse Gallagher about his experience with XPages and his evolution from a Comp Sci Java Developer and self taught Rails guy to Lotus Notes and beyond.

Jesse is a scary smart guy but what is special about him is that he is very eloquent with it. People this smart are rarely blessed with people skills and I think it is clear from the podcast he is very amiable, easy to talk to and scary smart. I had the pleasure of meeting Jesse in Pittsburgh at MWLUG2012 and I look forward to carrying on the conversation over some beers at #Connect13

We talked about Single Page Application development, coding standards, simplifying code development techniques, Java, Dojo, Ruby, Rails, ExtLib, Cats, jQuery and how we are planning to bride the IBM development team to include Web Sockets in the Domino server. #BringWebSocketsToXPages

One of the things I like about this show (and many other Taking Notes Podcasts) is that really sounds like the four of us are sitting around a table having a beer and chatting about life and XPages in general – love it.

Thanks to Bruce and Julian for having me on the show again and I look forward to the next one 🙂

Using jQuery to test if a checkbox on your XPage is checked

I have a checkbox and if it is checked I need to hide a table. How can I test if it is checked or not in a simple fashion?

Here is the checkbox

<xp:checkBox text="Audit" value="#{project.audit}" id="checkMarky">

And here is my table

<xp:table styleClass="markyTable" style="width: 100%">
<xp:tr >
	<xp:td styleClass="td1" colspan="4">

When the page Loads
When the page loads I determine if the table needs to be displayed or not based on the checkbox status. Using the “.is()” function I can return true or false and then based on that I can determine if the table is hidden or not.

	//test if the id ending in checkMarky is checked
	if ( $('[id$=checkMarky]').is(':checked') ){
		//if so then hide all items with the class markyTable
		$('.markyTable').css('display', 'none')

Toggling the Table
And then in the onChange event of the checkbox I make a very simple change using slideToggle. In the onLoad I determined if the table should be hidden or not – so if the status if the checkbox is reversed (changed) then either show or hide the table – and in this case use nice transition as well just as a bonus.


.is(‘:checked’) is the secret sauce in this example and returns true or false if the checkbox is checked.

library.onLoad – what does it do and who loads last?

In this article I will demonstrate that there multiple methods for determining the “onLoad” event of you page and discuss which method you should use and when.


Once upon a time when the world was young and we did not have JavaScript libraries we had the onLoad event of the document.

	<body onload="alert('Hi Marky')">

This caused some issues in itself because it indicated that the HTML was loaded – but did not have any knowledge of the images on the page and they might not have finished downloading – so this was not a reliable way of determining if the page was really loaded.

Then came the Library

If you are including functionality from a Library there is a high probability that the Library is doing some sort of Document Model (DOM) manipulation when the page loads – it has to do this to provide the functionality you are asking it to do.

Take your XPage as a prime example – you are including (well ok the XPage is including) the dojo Library and with that the XSP library built to provide XPage functionality. If you look at the source of an XPage containing a date control you will see this

<input id="view:_id1:_id2:_id39:inputText2" class="xspInputFieldDateTimePicker" type="text" name="view:_id1:_id2:_id39:inputText2" />

But if you look at the HTML created AFTER dojo and the XSP have done their magic the field looks like this!!

<span class="xspInputFieldDateTimePicker" style="display: inline-block;">
<div id="widget_view:_id1:_id2:_id39:inputText2" class="dijit dijitReset dijitInlineTable dijitLeft xspInputFieldDateTimePicker dijitTextBox">
	<div class="dijitReset dijitValidationContainer"><input class="dijitReset dijitInputField dijitValidationIcon dijitValidationInner" tabindex="-1" type="text" value="? " readonly="readonly" />
	<div class="dijitReset dijitInputField dijitInputContainer"><input id="view:_id1:_id2:_id39:inputText2" class="dijitReset dijitInputInner" tabindex="0" type="text" value="" />
		<input style="display: none;" type="text" name="view:_id1:_id2:_id39:inputText2" />

<span id="view:_id1:_id2:_id39:inputText2_Container" class="xspInputFieldDateTimePicker" style="display: inline-block;">
	<span class="dijit dijitReset dijitInline dijitButton xspInputFieldDateTimePicker">
		<span class="dijitReset dijitInline dijitButtonNode">
			<span id="dijit_form_Button_0" class="dijitReset dijitStretch dijitButtonContents" style="background-image: none; margin: 0px; border: none; padding-left: 0px; background-position: 0% 0%; background-repeat: initial initial;" title="">
				<span class="dijitReset dijitInline dijitIcon xspInputFieldDatePickerIcon">
				<span class="dijitReset dijitToggleButtonIconChar">?</span>
				<span id="dijit_form_Button_0_label" class="dijitReset dijitInline dijitButtonText dijitDisplayNone">
		<input class="dijitOffScreen" tabindex="-1" type="button" value="" />

And that doesn’t happen in an instant – it takes time……and if we want to programmatically interact with the “new” date picker code we have to wait for the dojo and XSP to do their thang.

This is where library.onLoad comes into play – it is an event triggered when the library believes that the page is safe to interact with – i.e. everything it needs to do is complete.


The dojo.addOnLoad page explains better than I can

dojo.addOnLoad is a fundamental aspect of using Dojo. Passing addOnLoad a function will register the function to run when the Dom is ready. This differs slightly from document.ready and body.onload in that addOnLoad waits until all dojo.require() (and their recursive dependencies) have loaded before firing.


The XSP is a library built on top of a library and has dependencies on the dojo library.

In our XPage environment we have the onClientLoad event accessible from the XPage event section – this is actually the GUI equivalent to XSP.addOnLoad which is a programmatic function we have available through the XSP library.


jQuery – $(‘document’).ready()

jQuery’s version of this onLoad capability is described as follows:

While JavaScript provides the load event for executing code when a page is rendered, this event does not get triggered until all assets such as images have been completely received. In most cases, the script can be run as soon as the DOM hierarchy has been fully constructed. The handler passed to .ready() is guaranteed to be executed after the DOM is ready, so this is usually the best place to attach all other event handlers and run other jQuery code. When using scripts that rely on the value of CSS style properties, it’s important to reference external stylesheets or embed style elements before referencing the scripts.

These people are so much more eloquent that I 🙂

So if everyone fires when the DOM is ready then they should all fire at the same time…right?

Well that is what occurred to me and I wanted to find out – people have told me through the life of this blog that I should always use the XSP.addOnLoad because it fires when the XPage is ready – but if I use jQuery is that ready as well?


It is really not all that complicated to test who fires first – what I created was a variable to track when the page started to load and then asked each library to subtract the time when they fired “when the DOM was ready” and write it to the page. This code sample was added to the top of my XPage so the variable “a” is created immediately when the page is loaded and each library then triggers when it is ready.

<script type="text/javascript">// <![CDATA[
		var a = new Date()
		document.write("Started at: "+a)

			// alert('jQuery')
			var b = new Date()
			document.getElementById('divJquery').innerHTML = b-a
			var s=document.createElement('div');
			s.innerHTML = "<div>"+"jQuery - "+(b-a)+"</div>"

			// alert('XSP')
			var c = new Date()
			document.getElementById('divXSP').innerHTML = c-a
			var s=document.createElement('div');
			s.innerHTML = "<div>"+"XSP - "+(c-a)+"</div>"

			// alert('dojo')
			var d = new Date()
			document.getElementById('divDojo').innerHTML = d-a
			var s=document.createElement('div');
			s.innerHTML = "<div>"+"dojo - "+(d-a)+"</div>"

// ]]></script>

and in the onClientLoad event

			var e = new Date()
			document.getElementById('divOnClientLoad').innerHTML = e-a
			var s=document.createElement('div');
			s.innerHTML = "<div>"+"onClientLoad - "+(e-a)+"</div>"


You can see the page I created to test this experiment here


You will see that there are a lot of typeAhead and date picker fields on the page – the reason I did this was to slow down the loading of the page – The libraries were all firing very close together and I wanted to see if I could separate them by delaying the page loading – it didn’t see to make a difference they all fired with the same delay between them.

The results

Well I have to say I was surprised and very glad that I created this experiment because it will change how I determine when the DOM is ready in the future. You can keep testing this for yourself by refreshing the test page above but you will see consistently that the libraries fire in this order:

Library Time to
DOM ready (ms)
Dojo 198
XSP 197
onClientLoad (XSP) 198
jQuery 209

As you refresh the page you will see different load times but they are always grouped XSP, clientOnLoad

results of load order
results of load order

Why are these different?

Each library determines when they believe the DOM is ready differently – each one is assuming that the DOM is ready when everything is loaded for it’s own library (naturally dojo doesn’t care when jQuery is loaded). For some insight check this StackOverflow post out

How does the jQuery ready() function work?

From my experiments I noticed that dojo, XSP and onClient load were always no more than 1 milisecond apart and each one of them sometimes came first – i think there is an aspect of the fact that they are all trying to create a DIV and append it to the page (my test code) and that has some nominal time associated with it and they are all trying to append to the same DOM element – for the sake of statistical accuracy my observation is that dojo is usually the first to record a result but because it is not always first I cannot claim that categorically.

I also have to add that there is a discrepancy with the onClientLoad test because it does not use the same variable as the other libraries – because it is being added to the page in a different fashion it is not an identical test. I am not however going to add the whole of the code to the onClientLoad event because then I would be asking the onClientLoad event to trigger the other libraries which isn’t right.


So here is the important things to remember when you are developing your xPage

  1. Never use dojo.addOnLoad – it fires almost exactly the same time as the XSP but more importantly your xPage XSP library is not ready
  2. If you are using jQuery *always* use $(‘document’).ready()
  3. Otherwise use XSP.addOnLoad/onClientLoad

It is interesting to see that jQuery takes longer to be ready and why that is, is way beyond the comprehension of this developer but there is a clear separation and because almost all of my work uses jQuery in one fashion or another I will always use $(‘document’).ready()

Please feel free to argue my experimental methodology if you think it can be improved 🙂