XPages

Dojo ToolTips

Tooltips are one of those little features which you rarely have the time to add to your website (beyond the basic title settings of your HTML elements), but do add a surprising amount of polish to your application from your user’s point of view.

In an application that I have been working on recently, we added some tooltips to convey some specific information on how to use certain features and the extra help went over really well. But how do you add them in XPages?

Well Dojo is your friend, and more specifically one of the “dijit” package of plugins called dijit.ToolTip. So in your XPage you add a computed field with the display type set to HTML. In the value of the field add the following:

“<div dojoType=\”dijit.Tooltip\”\n” +

“connectId=\”” + getClientId(“hoverlabel”) + “\” style=\”display:none;\”>\n” +

“This is a tooltip\n” +

“</div>”;

Basically what we’re doing is creating a div that will get written out to the browser, the important elements are the dojoType which tells Dojo that this is something it needs to look at when the page loads. The connectId links the div to the label which we want to add the tooltip to. So in this case, I have a label called “hoverlabel”. Set the div to be hidden using CSS so that while Dojo is processing it after the page load, it doesn’t appear and then disappear very quickly.

Finally we just need to make sure that Dojo is enabled on our XPage, so:

  1. Go to the All Properties of your XPage and then Basics, make sure that dojoParseOnLoad is set to true
  2. I also set the dojoTheme to true as well.
  3. Then in the resources property (still in All Properties -> Basics) click the Add button and choose xp:dojoModule)
  4. In the dojoModule -> basics -> name property which gets added, set the value to “dijit.Tooltip”

 It’s really very simple to get going and this is what you end up with:

A really nice looking tooltip with no coding on from out point of view that will be very helpful for your users.

New XPages Blog

Bruce (ever trying new things) has gathered together a few people who are using XPages a lot in their day jobs to form a group blog over at xpagesblog.com. Hopefully over the next weeks and months we can put together a really good library of XPages news, development techniques, tip and tricks for the community to use.

There’s already some good stuff up there, so it’s well worth a look.

Load testing XPages with the help of IBM

Mick Moignard and I have been down at IBM Hursley for a few days working on load testing an XPages application we’ve written for a customer.

Mick talks more about the (very impressive from our point of view) details, but I just wanted to add my voice to his in saying thanks to the team down there, especially Andy Walter who really helped us out with anything we needed, from server hardware, load testing software, expertise in building the kit and so on. 

If you are a BP in the UK then I’d highly recommend having a chat with the team down there. And I believe there are equivalent set ups in a lot of other countries around the world. It is nice to be able to praise IBM every now and again!

Human Readable Dates in XPages

Last year Jake published a really good article (as he generally does) about how to create Ruby style dates in LotusScript. So for example, instead of displaying “28/06/2009 09:35” the page will show “about 30 minutes ago”.

It’s a technique I bookmarked until I had a need for it, which I now have, but for an XPages app. So I have ported Jakes code across to use Server Side Javascript instead of LotusScript, and in “share and share alike” fashion, thought I should republish it for you to use as you see fit.

So you can download the code here: xpDates.jss 

Please let me know if you spot any bugs.

An interesting side note is, that if you compare Jakes LotusScript and my server side Javascript, you can see just how easy it is to port code from one syntax to the other. So if you’re just starting out in XPages development and are worried about losing all of your existing LotusScript agents, there really is no need to. You can spend (an admittedly boring) few hours reformatting and not lose any of your existing code at all.

It may not suit all cases, but for the majority of code it’s easier than starting from scratch.

How to add non breaking spaces to your XPages

Often when you’re designing a web page, you’ll need a space between elements (such as two field labels for example). Most of the time you should solve your UI issues with CSS, but sometimes that is not the correct answer. Enter &nbsp; this is a the classic non breaking space that you can use in HTML.

Unfortunately you cannot use that in your XPages source because it is not valid XML, so instead, we just have to use:

&#160;

160 is the decimal character code for the non breaking space and use of character code markup like this is valid in XML.

A very simple tip, but a useful one none the less.

Running XPages 8.5.0 in IE8

The first thing you’ll notice when you try and open an XPages website in IE8 is a Javascript error. The version of Dojo that ships with 8.5.0 is 1.1.1, this does not support IE8. Hopefully in 8.5.1 Dojo 1.3 will ship so this is a very short term fix.

The aim is for us to set a meta tag in our HTML to tell IE8 to run in IE7 compatability mode. Unfortunately, the built in way of setting meta tags in Domino Designer does not work properly yet so we have to manually add our own tag to the servlet response that the Domino server generates for us.

So if you put the following code into the “beforeRenderResponse” event of your XPage then you should find your site will work properly now.

try {
  if (context.getUserAgent().isIE(8, 8)) {
   var exCon = facesContext.getExternalContext();
       var response = exCon.getResponse();
       response.setHeader(“X-UA-Compatible”, “IE=EmulateIE7”);
    }
} catch (e) {
}

Kudos to Michael Gollmick for this solution.

How to get complicated data on the clientside in XPages without AJAX

So by now, if you’ve been playing with XPages at all, hopefully you’ll know about the #{id:myfield} syntax for referring to fields in your client side javascript. If not then you can read about it here.

But I thought it might be useful to break down that syntax and look at a couple of things which may not be so obvious.

Firstly is the hash sign (or pound sign for our American cousins). This basically tells the server that it can expect to process some server side Javascript dynamically, rather than as a one time calculation. If you had some totally static piece of information you wanted to compute you could use a dollar ($) sign instead. If you look at the source XML of your XPage then you can often see $ signs in the code for calculating the contents of your combo box options for example.

The second thing to mention is the “id:” element, this just tells the server that is is looking for a field on the XPage, in other words, it’s a reserved word. We are still in the stage of working out other reserved words here (that aren’t documented) but one option which really offers a lot of opportunities is to use “javascript:” instead. This will tell the server to run some server side javascript when it comes across the code. So, as a very simple example, in one of my XPages, I have some client side script that looks like this in DDE:

return contractorApprove("#{id:mybutton}", 
    "#{javascript:@UserName()}", 
    "#{javascript:document1.getDocument().getUniversalID()}", 
    #{javascript:document1.getItemValueInteger("numberfield")}, 
    "#{javascript:document1.getItemValueString('textfield')}"
)

becomes

return contractorApprove("view:_id1:_id4:_id6:mybutton", 
    "CN=Matt White/O=UITDemo", 
    "9B669EB8FC27551B802575C10040E62C", 
    8.0, 
    "Yes"
)

So going line by line. We are calling a client side Javascript function (which is written in a Script Library so has no context for where it is being called from, we want to pass in all of the data it needs to run) called contractorApprove. The first parameter is the HTML ID of the button which is being clicked, in DDE it’s called “mybutton” but on the browser it’s called “view:_id1:_id4:_id6:mybutton”, the server has done that translation for us.

The second parameter is where we get into the cooler stuff. I want to pass in the current user name, so I use the “#{javascript:” syntax and evaluate an @UserName() on the server and pass the result on the client side.

Likewise for the third, fourth and fifth parameters, I have a document binding set up on my XPage and I want to pass the document UNID and a couple of field values, one is a number, the other some text and I can pull these values from the document on the server side which means I can avoid having to put any more field controls into my XPage design. But you can see, hopefully, that if I had a more complicated piece of business logic, I could write it in a Server Side Script library and get the result using this technique and pass it to the browser without having to wrap it in a standalone agent, page or other Ajax wrapper that we might have used in classic Domino web dev.

Another repeat of the XPages workshop

It looks like Tim and I will be heading over to Stockholm, Sweden next month to give another version of the XPages Workshop that went so well here in the UK at the end of last year.

The dates are the 10th and 11th of March and you need to go here for more details. I hope to see you next month if you can make it.

XPages workshop (repeat 1) over

I am stunned that we got through all of the 26 exercises by mid afternoon yesterday, and other than a few errors in the scripts which we’ll have fixed for future versions of this course it seemed to go pretty well.

The feedback was pretty overwhelmingly positive and hopefully it means that the guys can go back to their offices and be able to write a new XPages app from their existing Notes applications.

We now have a few days to correct the scripts and VM images before the 9th when the second version starts. I think there were still a few seats left, so if you want to attend get in there quickly.