Not for the first time I came across something I had not been aware of before, and then had a second occurrence within a week. It’s something I’ll bear in mind for the future and, as such, I think it’s worth sharing.
The first occurrence was last week. I’ve long held it true that if you want an application broken, give it to end users – sooner or later they will break it in a way you hadn’t even envisaged. So I should not have been surprised when I deployed a new XPages application for UAT and the testers highlighted an issue caused by legacy data that had been imported in. The view had some fixed width columns to ensure the layout was clean, because the views were held in a container that adjusted to the size of the screen. Everything looked fine on the web (in both Internet Explorer and Firefox), with values wrapping accordingly. But in the Notes Client, sometimes a column holding a reference number would wrap, but on other occasions it expanded and would not wrap, as I found with the value “XXXXXXXX-XXXXXXXXX-SERVICES-21-10-2008-MR-10” (I’ve replaced some of the content with X to keep it more generic).
After trying various things and a bit of head-scratching, I despatched a desperate tweet and a very helpful member of the community informed me that XPiNC used an XULRunner equivalent to Firefox 2. After a fair amount of hunting on the web I learned something more about XULRunner, predominantly from this post, that it is a rendering engine developed by the Mozilla Foundation. Some more hunting on word wrap in table cells in Firefox 2 offered a few solutions. The most common was to force a carriage return at the appropriate place, which is fine if you’re creating a website and coding the content yourself, more challenging if you’re building applications. Another offered some CSS formatting to set “table-layout: fixed” on the table and “white-space: -moz-pre-wrap;” on the relevant column. This would have been ideal, but I couldn’t get it to work (that may well be because I was doing something wrong, my web development experience is not immense!). Finally the fall-back was to set the se for the table cell to “overflow: hidden”. This meant that part of the reference number was not visible, but because the application was based on a spreadsheet and because the end users could open the relevant documents to see the full value, it sufficed for my requirements.
Then a couple of nights ago I was working on a personal XPages application which holds documents at different levels of a hierarchy. They’re not response documents, but a Position field allows me to order them correctly and I used a repeat control containing an empty xp:span with the style “padding-left: 20px” to indent to the correct hierarchical level and follow it with the XSPViewEntry title. This looked nice on Internet Explorer and Firefox, but when I happened to open the application in the Notes Client, I got a blank line with the title on the following line. My thoughts immediately jumped back to the XULRunner, so my first attempt was to set the span’s style to “display: inline”, but it didn’t work. A quick look at the source, and I immediately realised the problem – the repeat control creates a div around the contents. Setting the style of the xp:repeat to “display: inline” instead of the span’s style solved the problem.
We’re running 8.5.1 FP1, so it’s a problem that’s still relevant. There’s no confirmed details on when this will be fixed, but I’m confident that it’s a case of “when” not “if” it’s solved. In the meantime, I consider it no more than a minor inconvenience. XPages still speeds up my web development to offer a rich user experience, and reduces the headaches of cross-browser compatibility. Plus it allows me to offer, on the whole, a consistent experience for Notes client users without needing to dumb down the functionality. I’m mnore than happy that Domino 8.5.1 gets me closer to the utopian ideal of build once, deliver twice.