Archive | XPages Tip RSS for this section

Domino Designer Tip – RegEx Searching for a String with Single or Double Quotes

If you’re looking for a string value in code throughout your application, it can sometimes be frustrating to weed through extraneous results. If you know the exact string, you can make the search more efficient by including the quotes in the search. However, if you’re working on someone else’s (because you would never do that) application where there’s inconsistent usage of single and double quotes throughout the code, you either have to search twice or you may miss some results. In this post, I’ll show how to do a single search to find all instances in single or double quotes.


Here’s a bad example that I can easily use as a straw man to illustrate the point.

I created an empty NSF and added two script libraries.

One has this line:
var x = 'doc';

The other has this line:
var x = "doc";

A search for doc (without quotes) brings back 13 results because it’s part of a bunch of words. And this is in an otherwise empty NSF.


In order to narrow the results, I can limit the search by wrapping the search term in quotes to find only instances of the full string. In this example, I searched for "doc"


This search only found the instance that used double quotes, but it misses the other instance in single quotes.

RegEx to the Rescue

Fortunately, Eclipse search can handle regular expressions. (H/T to Jessie Gallagher for that tip awhile back.)

Just check the ‘Regular expression’ box and use regex syntax for finding one of multiple characters (square brackets) to build a search string that will find the value with either single or double quotes.



And now I get the results I was looking for, including the term in both single and double quotes.


Note: If you only know part of the term, you can use wildcards or just include the quote search on one end of the term.


Fixing the Width of a Select 2 with a Long Value in a Bootstrap Form Group or Input Group

If you have a Select2 control within a form-group or input-group div in a Bootstrap UI, a long value can cause the Select2 to grow to become wider than its container. In this post, I’ll show how to fix the issue.

The Problem with Large Values

In this demo, I have a form with two columns of fields, each within a well (which makes the container size very clear).

Select2 Long Values - A

In one field, there is a very long value. This usually isn’t an issue when you have explicit control over the options, but if you have an application where a drop-down box’s choices come from a plain text field on other documents, it’s possible.

Select2 Long Values - B

When I select the long value, it limits the amount of text displayed in the box to what will fit on one line, but it expands the size of the Select2 outside of its container.

Select2 Long Values - C

If I remove the second column of fields and re-test, it looks like the Select2 was enlarged to be the same the size as the parent container, which is too big for the area that it’s supposed to be in.

Select2 Long Values - C2

Fixing with CSS

This is a known issue with Select2 inside of a form-group or input-group within Bootstrap.

Fortunately, there’s a simple CSS fix, adapted from this post on github

.form-group .select2-container {
  position: relative;
  z-index: 2;
  float: left;
  width: 100%;
  margin-bottom: 0;
  display: table;
  table-layout: fixed;

If you’re using an input-group instead of a form-group, then change the first line to this:

.input-group .select2-container {

Select2 Long Values - D

XPages Tip: Reading Custom Properties and Modifying a Component Before a Page Loads

If you need to read a property on a custom control and do something to any component on the page before a page loads, it can get tricky because the compositeData object is not available in the beforeRenderResponse event and getComponent() does not work in the beforePageLoad event.

I have an application where I need to dynamically inject components before a page loads. However, the injection depends on custom properties on a custom control, so it needs to read the properties and then get a handle to a component and modify it. Since the compositeData object isn’t available in the beforeRenderResponse event and getComponent() doesn’t work in the beforePageLoad event, there’s no single place to put the code that I need.

Fortunately, there’s a simple workaround. Code in the beforePageLoad event can read custom properties from the compositeData object and store them in viewScope variables. Then, code in the beforeRenderResponse event can read those values from viewScope and use getComponent() to get the handle to the component that I need to modify.

Fixing an Issue with Glyphicons with a Bootswatch Theme in XPages

In this post, I’ll describe an issue that I had with glyphicons when using a Bootswatch theme in XPages and how to fix it.

When you use a Bootswatch theme, you do not need to separately include the original
bootstrap.css file. In fact, it would be inefficient to do so, because the styling is provided by the Bootswatch CSS file.

When adding any additional Javascript libraries or CSS to an XPages application, I generally put them in their own folder under WebContent and then include the library or stylesheet via the application theme.


However, I noticed an issue when doing this recently. The Bootswatch theme styling loaded fine, but glyphicons on the page were
not displayed properly; the unrecognized font character symbol was displayed instead.

Glyphicons are loaded as a font (much like Font Awesome), so I looked through the stylesheet to see how the font was included. As you can see, the reference is relative to the current directory, assuming a standard Bootstrap directory structure.

@font-face {
  font-family: 'Glyphicons Halflings';
  src: url('../fonts/glyphicons-halflings-regular.eot');
  src: url('../fonts/glyphicons-halflings-regular.eot?#iefix') format('embedded-opentype'), url('../fonts/glyphicons-halflings-regular.woff2') format('woff2'), url('../fonts/glyphicons-halflings-regular.woff') format('woff'), url('../fonts/glyphicons-halflings-regular.ttf') format('truetype'), url('../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular') format('svg');

There are two ways to go about fixing this:

  1. You can update the font references to be relative to the actual directory structure.
  2. Much more simply, you can move the bootswatch CSS file into the css directory under the bootstrap directory so the relative font file references work without being modified.

XPages Tip: Displaying View Panel Sort Icons on a Separate Line

If there isn’t enough room to display both the column title and sort icons in all column headers in a view panel, you can end up with an uneven look. In this post, I’ll show how to use CSS to move the sort icons down to a new line.

Column Header Layout

If you’re using a view panel with sortable columns, you will ideally not have too many columns and instead have enough screen real estate that the sort icons don’t make a difference.

View Panel Sort Icons - 1

However, a common scenario is that there are a lot more columns crammed in and some (but not all) sort icons wrap to a new line. This ends up causing an uneven look.

View Panel Sort Icons - 2

In addition, the icons take up space, so you may have columns that have a 1- or 2-letter code, but the sort icon makes the column 2-3 times wider than it needs to be, so you lose precious real estate.

If that happens and you’d like to make them consistent, you can use CSS to always move the sort icons to the next line.

Column Header Source

In order to apply CSS to adjust the layout, we need to view the page source to see what’s being generated.

This snippet contains the tags that start the view panel (line 1), start the column header row (lines 2-3), and display the first column header (lines 4-16).

<table id="view:_id1:viewPanel1" class="xspDataTable">
      <th scope="col">
        <div class="xspPanelViewColumnHeader">
            <a id="view:_id1:viewPanel1:viewColumn1:__internal_header_title_id" href="#" class="xspPanelViewColumnHeader">
              <span class="xspPanelViewColumnHeader">Group</span>
            <img id="view:_id1:viewPanel1:viewColumn1:__internal_header_sort_icon" src="/domjava/xsp/theme/common/images/sort_none.gif" 
alt="Sort Toggle" title="Sort Toggle" class="xspImageViewColumnHeaderSort">

This shows that a column header div contains a span with the column title and another span with the sort icon.

Adding a New Line with CSS

This gives us enough information to know how to target the proper element with CSS. There are several ways to go about it. My example will target the table (with class name), div (with class name), and then get the first span tag. It will add the new line after the first span.

table.xspDataTable div.xspPanelViewColumnHeader span:first-of-type:after {
  content: '\A';
  white-space: pre;

The '\A' in the content attribute denotes a new line with CSS. It does not work to put a <br> tag there. The white-space attribute is also required or you may not see any difference.

Now, all of the sort icons appear on a separate line.

View Panel Sort Icons - 3

You can tweak it by adjusting the space between the lines or centering, etc, but this gets the ball rolling.

Also, if you want to modify the images themselves, you can target .xspImageViewColumnHeaderSort with CSS.

XPages Tip — Adding Attributes to the HTML Tag

By default, the HTML tag rendered for an XPage only includes an attribute for the page language (<html lang="en">). In this post I’ll show how to add additional attributes to the HTML tag rendered for the page.

Adding an Attribute

You can add an attribute to the HTML tag via the attrs property, which can be found in All Properties > basics > attrs. Click the plus (+) button to add an attribute and then specify the attribute name and value.

HTML Attribute

Here is what’s added to the page, below the tag:

  <xp:attr name="myAttribute" value="myValue"></xp:attr>

When the page is loaded in the browser, you can see the attribute in the source:

<html lang="en" myAttribute="myValue">


One handy use for this is the HTML5 manifest attribute, which specifies the location for caching the page for offline and faster access.

Here’s an example:

  <xp:attr name="manifest" value="myCache.appcache"></xp:attr>

Note: If you want to use an HTML5 feature, you need to change the HTML doctype to HTML5 on the Page Generation tab of the Xsp Properties design element.

Default doctype:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">

HTML 5 doctype:

<!DOCTYPE html>

There are other global attributes that can also be applied to the HTML tag, such as id, style, dir (page direction – left to right or right to left), but there are other built-in properties for those on an XPage, so there isn’t a need to set them with a page-level attribute.


In order to be applied to the HTML tag, the attribute must be defined at the XPage level. If added to a custom control, they’ll become attributes of a <div> tag.

XPages Tip: Component API Documentation

I’m sure you’ve seen the standard XPages Reference that’s part of the Domino Designer help, but you may not be aware that there’s also API documentation for XPages controls that’s available. It’s documentation of the API for the underlying Java classes and it can be very useful in letting you know what methods are available for each component.

Here’s an example for an Input Text control. At the top of the page, you can see the class hierarchy that leads to the component.


This gives you the ability to also find methods that are available to higher-level classes from which this component inherits.

You can scroll down to see a summary of the methods available.


If you scroll further, you can get a more detailed description of the methods.


It can be helpful to peruse the list — you may come up with ideas to work with the component in ways that you didn’t realize were available because there isn’t a built-in property in the UI!

The API for standard components (9.0.1) can be found in the XPages Components documentation. Do yourself a favor and keep the link handy — it’s not exactly easy to find.

In addition to the XPages component documentation, you can also go up a level in the API and see documentation for many more classes in the runtime (9.0.1).

I had a bookmark for the same info but with a much nicer interface on the OpenNTF site, but it is no longer valid. That included the API for all xp and xe components in on place and was an excellent reference. The documentation comes with the extension library (under \Docs\ExtLib\XPages-Doc\control.html), though, so make use of it if you have that available. If you have a link to this online — please let me know and I’ll update this post.

Update: Many thanks for a quick response from Per Lausten — the link for the controls documentation on OpenNTF has been restored!