Monthly Archives: November 2012

Preventing the XPages Dialog control to auto center

If you ever tried to use a XPage dialog control from the extension library on a mobile device. You’ll probably seen this behavior, the dialog is moving away each time you try to click on a button or a field in the dialog.

The trick to fix this is to force the dialog to a fixed location if you are on a mobile device with a small screen.

There are several ways to detect this:

check out this stackoverflow question how to detect iphone by CSS –>Link

You can use this xSnippet –> Link or this post by Keith Strickland –> Link

When you can detect this and depending on your approach place the following code in a stylesheet

or if you place it directly as a computed style on the dialog.

The following css properties is that makes the dialog to stop moving around. 

top:100px !important;
left:100px !important;

This will force the dialog to be placed at position 100,100 on screen. !important is a css property that forces an override of other properties set.

So what I usually do to fix this is add the xSnippet in a SSJS Scriptlibrary and add the following code as a computed style property on the dialog 

return "top:100px !important;left:100px !important;"

Enjoy your mobile application 

Use the same datasource everywhere in XPages

When using custom controls there are several ways of binding fields to backend fields.

1. Create a datasource with the same name as the datasource you are using for the fields

(Warning! if you forgett to remove this when you are done you will get a replica conflict)


2. Pass the Datasource into the custom control and use the compositeData.propertyname[“fieldname”] to bind to the field. This article describes how to do this –>Link


3. Use a save function and retrieve the values from the fields and save the information to fields. This would also require a load function to populate the fields.

And there are probably several more ways of doing this, that is often the problem with XPages you get multiple ways of doing things and you don’t know the right way.

If often use number 1 when I’m creating xpages, the problem with this way is that if you have to add a new fields later you have to add the datasource again if you would like to use the simple binding dialog.

But there is another way, add a datasource with the variable name and properties as you main datasource. Go into source mode and add loaded=”false” to the data sources on you custom controls, you can still use the simple data binding and you will not get any replica save conflicts because this datasource isn’t loaded.

This is what you source should look: 

Hope this will help you get rid of some annoying replica conflict when you have forgotten to remove a datasource. Enjoy!

Working from the mailbox

I saw this great video a couple of days ago about the future of Collaboration

Great show how IBM Tech could help you to be more productive. But then I thought how could a organization be more productive today.

One thing could be to start sending smarter emails, make sure that you applications don’t just send stupid plain emails.

Add productive addons today, if your application sends an approval request to the manager, send the information he or she needs directly in the email. Add an approve / reject link in the email.

Move some of the logic to the mailbox of your users today and see what they think.

You could if your users are using the Notes client use the function “attach form” in the send function to send a complete Lotus Notes form with logic to your users. Add a comment field below the email and a send comment.

(Remember all the code must be inside the form, you can’t have i.e external LS libraries.)






Let’s save a couple of minutes for a user Today!


Make your Domino Designer more responsive and stable

I came across a support document by IBM telling that increasing memory in the Domino Designer will make the client more responsive and stable.

This document also introducted another memory parameter xmca this parameter is now added to

The Designer memory configurator version 1.2  Link

Adding a dojo calendar control to traditional Notes date fields

When web enabling old Domino forms date fields has never been fun. users setting the wrong format, and the save breaks the form giving a error 500. There has been alot of dhtml calendar pickers that has been used some better and some worse of handling other browses than IE.  We all have these applications that is  very large and that you don’t can convert directly to XPages, then adding dojo to your old forms can help you.

 What do you need to do to get a dojo calendar control to work with a old date field in a form, not much actually. Dojo is really good of helping you to do this move.

First you have to decide if you want to host the dojo toolkit locally or thru i.e Google CDN.

It’s just the url:s in my example that you need to change if you want to host the dojo files in the html directory on your Domino server.

Add the following with passthru html to a subform

<script src=""
djConfig="parseOnLoad: true"></script>
<script type="text/javascript">
<link rel="stylesheet" type="text/css" href=""/>

In 8.5.3 you could use this internal url to dojo instead of the CDN

When this is done you need to add this subform to your form.

You also need to add the theme class to the body attribute section of the form. 



On your date fields on the form add the following to the HTML attributes to the field

“dojoType=\”dijit.form.DateTextBox\” ” 

And your done, add the last row to all your date fields to get a calendar control in all of them.

This calendar control will use browser locale when deciding how the date should be displayed.

Or you can like I like to do set a pattern that matches the date format on the server by changing the dojo type we specified on the field to

“dojoType=\”dijit.form.DateTextBox\” constraints={datePattern:’yy-MM-dd’}”

The Dojo series will continue with more controls both in traditional Notes and in XPages.


Dojo and jQuery part 2

Part 2 should have been some more examples but I feel that I need to write some about the response on my first part there where alot of comments discussing different things around Dojo vs jQuery.

First I like to say that my compare between these two was to show that you can do the same things with Dojo as you can do with jQuery and the code does look almost the same, also that Dojo has so much more inside the “package”. 

Joacim wrote why are you comparing an older version of Dojo than jQuery well because I´m mainly working with Dojo and xPages and the Domino server currently has an old version of Dojo and jQuery would be an addon to the server and then be of the latest version. But also to point out that even though Dojo 1.6 is 2 releases old you still can still use it and it will work great, and there is no need for jQuery. If you should learn one client side library it´s Dojo because this is what IBM is using for all the things in XPages.

I will continue with my Dojo travel in part 3 and that one will include some code I promise 😉

HTML manipulation Dojo vs jQuery

I have seen some writing by TexasSwede about how to use jQuery for manipulating the DOM and it seams easy but why import another toolkit for manipulating the DOM? Well perhaps if you know jQuery that might be the case or that you think jQuery is better. 

Let’s compare jQuery vs Dojo for some simple DOM changes. I’m using the latest jQuery 1.9 vs Dojo 1.6, why not the latest version well because XPages currently has 1.6 and because 1.8 has a different syntax.

let’s add the class pretty to every a tag in the page


  $("a").each( function() {
    var tag=$(this);


 dojo.query("a").forEach(function(node, index, arr){

The code is quite similar in both Dojo and jQuery, I don’t know about speed perhaps some of you readers know?

I’ll move forward in part 2 with some more Dojo stuff, stay tuned.

PS!Don’t forget to change your email signature

Sent from Lotus Notes – More than an inbox