Managed properties

For an application we aggregate the data from several servers and databases. In SSJS applications I tend to save such properties in Notes configuration documents and store them in scoped Variables during initialization. Something like was provided in the XPages Framework a while ago.

In episode 182 of Notes in 9 David Leedy gives a great demonstration how to work with Notes documents via Managed Beans. However for properties that should not be altered likely by an application administrator (could be the application owner, a regular Notes user) I tend to work with managed properties. With managed properties you more or less configure your managed bean.

So how could this look like?

In the faces-config.xml I set the properties for a managed bean e.g.

<?xml version=”1.0″ encoding=”UTF-8″?>



which I can use then in my java code:

package com.wordpress.quintessens;
public class ConfigBean implements Serializable {
private String dataSource;
//… more variable declarations

public JsonJavaObject loadBackEndConfig(String Key) throws NotesException {
JsonJavaObject json = null;
NotesContext nct = NotesContext.getCurrent();
Session session = nct.getCurrentSession();
String DatabaseName = session.getCurrentDatabase().getFilePath();
String ViewName = “(LookUpBackEndConfig)”;
try {
json = loadJSONObject(this.dataSource, DatabaseName, ViewName, Key, 1);
} catch (NotesException e) {
// TODO Auto-generated catch block
return json;

public void setDataSource(String dataSource{
this.dataSource = dataSource
public String getDataSource() {
return dataSource


You can check if the value is passed correctly e.g. via Expression Language:

<xp:text escape=”true” id=”computedField1″

I am curious how you prefer to configure your applications? In some cases I find it perhaps an overkill to store the configuration in Notes documents and publish the values via a managed bean.

Happy development =)


prettytime for your XPages


I guess most of us believe that not all users are robots, and especially in social applications where you try to approach humans as human friendly as possible the display of date and time in such format can be off added value.


There are many scripts to display date and time in a human friendly format. For a project we are using timeago, a jQuery plugin that makes it easy to support automatically updating fuzzy timestamps (e.g. “4 minutes ago” or “about 1 day ago”).

However, in combination with an infinite scroll feature to navigate through document collections we notice that the script not always return instantly the transformed date/time.

That is why I looked at a server-side transformation.


PrettyTime is an OpenSource time formatting library. Completely customizable, it creates human readable, relative timestamps like those seen on Digg, Twitter, and Facebook.

It turned out the implementation of PrettyTime was quiet simple. I will describe the steps for you.

Install the jar & call the Java class

Download the project jar file and place it in the WebContent \ WEB-INF \ lib folder.  For a computed field on a custom control in a repeat control I have as SSJS code to call the Java class:

<xp:this.value><![CDATA[#{javascript:var theDate = compositeData.Date;
p = new org.ocpsoft.pretty.time.PrettyTime();
p.format(new Date(theDate))}]]></xp:this.value>

As a result I get to date displayed as:


Pro’s & Con’s

In comparison with client-side solutions I have detect some con’s and pro’s for a server side solution:

  • Static; the client side solutions are capably of updating the date/time value on the fly.
  • Speed; the server side generated human friendly date is there when a document row is presented.
  • Extensibility; the number of display languages is more numerous for most client-side solutions. Also you can often “configure” the text format when desired.
  • Consistency; having a human friendly date in a local language may be in conflict with internationalization of your XPages app since that might require more work.

Anyway: I happy to hear how you have solved the human friendly date issue.

Happy development!

new release XPages OpenLog Logger and custom runtime error page


Good news for me! In an XPage application I wanted to provide an error logging function and preferably to OpenLog. I had problems with implementing the previous version of OpenLog logger but yesterday a new version is released on OpenNTF which took away that pain.

OpenLog logger

The OpenLog logger has some powerful features:

  • It can be used in your managed beans and other Java classes.
  • It can be used directly from SSJS with as little as openLogBean.addError(e,this);.
  • From SSJS all caught errors on the page are logged out together, at the end of the request.
  • Only two method names are used from SSJS, one to add an error, one to add an event, making it easy to pick up
  • From SSJS you only need to pass the information you wish. There is no need to pass nulls or empty strings.
  • From SSJS only one unique error per component is logged, regardless of how many times the error is encountered during the refresh lifecycle.
  • In SSJS, if you use a custom error page, uncaught errors will also be logged.
  • Uncaught errors will be logged for the page the error occurs on, not your custom error page.
  • You can define the OpenLog path and a variety of other variables without needing to change the code.
  • The functionality and code are available as an OSGi plugin (the best practice approach) but can also be included in individual NSFs.

Custom Runtime Error Page

In case you want to implement such functionality then I recommend you also take a look at how to define a custom run time error page. In my project I am using Bootstrap for UI look & feel, so I followed the steps Erick McCormick provides in this blog post.


In Erick’s post you will find that he uses Google’s code-prettify project. A nice feature is to ability to set a skin for the error message box. There are plenty of color themes available for the prettify project but if you use Bootstrap like I do you could try this theme.

A big thank you to the OpenLog logger project members and Erick!



Uninstalling Java extensions (“plugins”)


Yesterday I tried to install the OpenLog logger plugin in my development environment (Notes 9.0.x) to add some more common logging procedures to an Xapp (XPages application).

Unfortunately the installation failed and I received an error message ‘no accessible features found for this plugin’. The plugin was not available under application management so from there I could not undo the installation and deleting the plugin from the data\workspace… resulted in an error when starting up Designer.

So I feared a new setup of my development environment but luckily the first result after the query ‘lotus designer remove installed plugin’ was at help. I just repeat them here so I know I have stored it somewhere:

Complete guide to manually uninstalling “plugins” from Lotus IBM Notes

The complete steps to manually uninstalling a Java extension is therefore as follows:

  1. Close Lotus Notes
  2. Open the “features”-directory (<Notes data dir>\workspace\applications\eclipse\features)
  3. Locate the Eclipse features to uninstall.
  4. For each Eclipse feature you need to open it and edit the feature.xml file. Locate the <plugin>-tags and fine the names of the referenced plugins. Note that there might be more than one. Combining the plugin id and the plugin version will give the full filename of the plugin (<plugin id>_<plugin version>.jar).
  5. Delete the Eclipse features you’re uninstalling.
  6. Open the “plugins”-directory (<Notes data dir>\workspace\applications\eclipse\plugins).
  7. Delete the plugin JAR-file(s) you recorded in the step above.
  8. Open the directory containing the platform.xml file (<Notes data dir>\workspace\.config\org.eclipse.update).
  9. Edit platform.xml and go to the end of the file.
  10. Remove each entry you see for the features you deleted in the step above.
  11. Save and close the file.
  12. Since Lotus Notes also keeps a record of which Java extensions to load it’s best to start Notes with some parameters to make it recompute the Java extension registry: notes.exe -RPARAMS -clean

Good news

I posted the problems I experienced on the OpenNTF project page and Paul Withers answered he is working on a newer version of the plugin. Hopefully that one will work brilliantly in Notes 9 clients…

Infinite scroll and prevent multiple event fire

Probably a lot of you use the “Simple custom control to add infinite scrolling to repeat or views” available as codesnippet on OpenNTF.

This snippet allows you to load a next set of documents for a repeat or view control when you reach the bottom of the page. A feature that will be appreciated highly by mobile users of your Notes app.

If you look at the code, it fires the click event of a pagerAddRows control when you have reached the bottom of the window. This will happen as long as you are on the bottom of the window. What can this cause for disturbance:

  • It fires multiple events, while it is at the bottom of the window. You only asked for 1.
  • The events are not chained so when the second event is returned quicker that the first it will be inserted before it, which messes up the sorting of your collection.

I have not found a way to create a JS function to load a set of data from a repeat control in the ajax way. That would allow you to use the success property and set a state (ajaxready, true/false) for your window. This state could be used to check if the fire event is entitled to run or not.

Drop a line in cause you know the answer to such a function.

As a temporarily solution I suggest to keep the click event for the pagerAddRows control but set a timeout.

Here is what the code could look like:

<xp:scriptBlock id=”scriptBlock1″>
<![CDATA[$(window).data(‘ajaxready’, true).scroll(function(e) {
if ($(window).data(‘ajaxready’) == false) return;
if ($(window).scrollTop() >= ($(document).height() – $(window).height())) {
$(window).data(‘ajaxready’, false);
setTimeout(function() {
$(“.infiniteScroll ul li a”).click();
dojo.query(“.timeago”).forEach( function(el) {
var timeagoWidget= dijit.getEnclosingWidget(el);
timeagoWidget = new timeago.Timeago({}, el);

//refresh timeago
$(window).data(‘ajaxready’, true);
}, 200);


Here is set a timeout for 200 milliseconds which turns out to be quiet generous in my application, but at least I have prevented the disturbances mentioned earlier.

Happy coding!

Make the search bar in the Application Layout control ‘sticky’


I guess many of you have or are using the Application Layout control (depending on your willingness of coping with limitations) and use Bootstrap to ‘escape’ IBM’s oneUI theming. In the control you can set the fixedNavBar property to fixed (top, bottom, unfixed?) but basically this will just claim precious space on top of the screen, especially for mobile users.

In case you are using the Search option in the Application Layout control you will find that usefull and want to have it available always and in particular for smaller devices where scrolling back to the top takes a bit more effort. Since you are already using Bootstrap the rescue is in near reach…


The Affix plugin in Bootstrap allows an element to become affixed (locked) to an area on the page. This is often used with navigation menus or social icon buttons, to make them “stick” at a specific area while scrolling up and down the page.

The plugin toggles this behavior on and off (changes the value of CSS position from static to fixed), depending on scroll position.

Implementation in XPages

Since we are using the Application Layout control we need to take a different swing than the normal implementation.

JavaScript onClientLoad

First we will add an ID to the titlebar section and then we register the affix plugin for it:

<xp:eventHandler event=”onClientLoad” submit=”false”>
<xp:this.script><![CDATA[$(‘.applayout-titlebar’).attr(‘id’, ‘titleBar’);
//in order to make it ‘sticky’ to the top…
offset: {top: 40}

CSS Styling

With CSS we define the style properties for the applied affix class:

#titleBar.affix {
position: fixed;
top: 0;
width: 100%;


That was rather easy, right?!

Below is a sample when an XPage is loaded:


And here is a sample when you scroll down the page:


Happy development!

Enforce HTTPS for my XPages

Sometimes it can be benefitial to enforce the https protocol. My use-case was that an XPages app was going to be opened from the mobile Connections app and just the HTTP protocol would case an additional login dialog to appear.

So the following SSJS code is what I came up with:

<xp:this.beforePageLoad><![CDATA[#{javascript:currURL = context.getUrl().getScheme();
if (currURL ==”http”){
var baseURL = context.getUrl().toString().toLowerCase();
safeURL = baseURL.replace(‘http’,’https’);

The code will check if the xpage is called with the http protocol, if so the same page is called but then with the https protocol enforced.

Since the application aggregates a lot of information from Notes views, which the application administrator can add, I also check if any URL’s with the http protocol are being displayed and transform them with the https protocol to reduce the first check:

<xp:eventHandler event=”onClientLoad” submit=”false”>
<xp:this.script><![CDATA[function toSSL() {
var current_host =;
var hosts = [‘’,’’,”’,current_host];
$.each( hosts, function( i, l ){
$(‘a[href*=”‘ + l +'”]’, ‘body’).each(function() {
var $a = $(this);
var href = $a.attr(‘href’);
if(href.indexOf(‘https’) == -1) {
var ssl = href.replace(‘http’, ‘https’);
$a.attr(‘href’, ssl);
$( document ).ready(function() {