One of the actions in an XPage application I’m building might take some while to complete. The action is triggered by a button so I added a loading indicator image that is shown on the button’s onStart event and hidden in the onComplete event. The problem with this was that it gives me no clue as to how long it will take and if it’s making any progress at all. So I searched for a way to display a real progress bar.

I investigated a solution involving a partial refresh of a part of the page while another partial refresh is running. This seemed a no-go: the 2nd partial refresh will not start/ complete until the first is finished. I also looked into threads and Eclipse jobs: but found that too complex for just a simple progressbar.

The solution I came up with includes a couple of components. In the (long-running) code I store the current progress (a number from 1 to 100) in a variable in the sessionScope. When the long-running code is started I use the onStart event to call a client-side function that uses the JavaScript setInterval() function to periodically call another XPage using a dojo.xhrGet(). That second XPage (getProgress.xsp) has only one purpose: it returns the progress from the variable in the sessionScope as JSON to the browser. This progress is then used to display a dijit.ProgressBar() with the updated progress. In the onComplete event of the long-running eventHandler I cancel the periodic checking.

Enough talk: demo or it didn’t happen.

You can download the demo database here. As far as I know the code will only work on 8.5.3. The demo page uses the built-in Dojo Claro theme. Oh,  and the messages are optional!

I’ve released version 1.1 of my Auto Logins for IBM Domino/ XWork server yesterday on OpenNTF. This release has a new XPages UI that makes the configuration easier and gives you a better insight in the tokens that have been stored.

I also fixed a couple of issues that were reported (mostly on Chrome) and added the option to restrict who can use the “remember me” option based on a IP range.

Go check it out!

Based on user feedback I got, I created a new release of my Remember me/ Auto Logins project on OpenNTF. This release contains the following changes:

• Updated error handling in case the configuration could not be loaded correctly (e.g. in case of a missing configuration document). In that case the “remember me” checkbox is also disabled.
• Sample login form updated for mobile usage.
• Scheduled agent added to cleanup expired tokens (“Remove expired tokens”).
• Added remote IP address to token document.
• -Default- users don’t need the ‘write public documents’ option anymore.
• UI Cleanup.

I just released version 1 of a new project of mine on OpenNTF. It is called “Auto Logins for IBM Domino/ XWork server“. You can use the application to add a “Remember me” option to any Domino/ XWork login screen. Based on an application setting the server can remember you for a number of days. When you re-visit the server, it recognizes you and will automatically log you in.

This is a great feature for any web (XPage) application, especially mobile web applications: it will make using the application a lot easier/ user friendlier.

The application uses the LTPA generator snippet that has recently been published on the XSnippet site by Serdar Başeğmez (thanks Serdar!). The algorithm that has been used for the remember me feature is described here.

I’ve written the application using a (customized) standard Domino login form and a couple of XPages (using managed beans). The user logging in is remembered by sending him a cookie. That cookie contains a token that is validated against a database of (hashed) tokens, including an expiration date. Note that the user’s password isn’t stored in any way or used in the cookie.

Update: The 1.0 release had local database encryption enabled. Download v1.01 for the version without encryption. 

I finally found some time to experiment with how to use source control in Designer. First thing I did was to setup an on-disk project: right click an application and click Team Development > “Set up source control for this application”. I let it create an on-disk project and added/ changed/ removed some design elements.

From what I knew it should automatically synchronize all those changes with the on-disk version of the application. It didn’t…

Took me quite some time (including a Designer re-install) to figure out that this was caused by the fact that I turned of the “Build automatically” option. Apparently the synchronisation process is tied to the build process.

Before committing I’ll test and to be able to test I’ll have to build, so it’s not a big deal. Just something you have to be aware off…

Bijgaand de slides van mijn “Beans en burgers” sessie tijdens het Social Business Event / NLLUG 2012 in De Kuip in Rotterdam. De sessie ging over het gebruik van managed beans in een XPages applicatie die ik onlangs heb ontwikkeld.

Download

dBar.info(message:String, context:String);
dBar.error(message:String, context:String);
dBar.debug(message:String, context:String);
dBar.warn(message:String, context:String);

Basic profiling using timers

dBar.startTimer( timerId:String );
dBar.stopTimer( timerId:String );

I extended the toolbar with stuff I also use regularly: lists of the contents of the various scopes (application, session, request, view), a list of variables always handy to have around, and Tommy Valand’s API inspector. Inspiration for this came from Ferry Kranenburg’s XPage Debug Custrom Control.

Improved object dumping

Usage and configuration

• custom control ccDebugToolbar
• (SSJS) script library xpDebugToolbar
• XPage debugToolbarConsole (only required if you want to be able to “detach” the messages tab)

Screenshots

I’ve updated the HTML mail SSJS library I wrote about yesterday and have added inline images support. This can come in handy when you want to create HTML newsletters.

Marking an image as “inline” can be done by adding an extra parameter to the addDocAttachment() / addFileAttachment() methods:

mail.addDocAttachment( "5203C670815BC8C4C12579270029C543", "header.gif", true );

The addDocAttachment/ addFileAttachment methods now return the Content ID of the image in the message. That ID can then be used to reference the image in the contents:

var headerImgId = mail.addDocAttachment("5203C670815BC8C4C12579270029C543", 
  "header.gif", true);

mail.addHTML("<table><tbody><tr><td>");
mail.addHTML("<img src="" + headerImgId + "" />;");
mail.addHTML("</td></tr></tbody></table>;");

If I send an email to my GMail account using my library containing only inline images, the email is considered not to have attachments (no paperclip icon in the messages list). If you have also chosen that images from that specific sender can always be shown, they also don’t show up at the bottom of the message (in the section containing all attachments).

To test if everything worked correctly I downloaded a sample HTML email template from FreeMailTemplates.com, uploaded all images to a sample database and created a mail message. In the downloaded index.html file I removed all line-breaks (rn) and tabs (t) using Notepad++. I then added the HTML (starting at the first table tag) to the message using the addHTML() method. I replaced all referenced images as described above. The message I received in GMail looked exactly how it was supposed to look:

I’ve tested the inline image functionality in GMail and Notes 8.5.3. You can download the library here.

Sending an e-mail from an XPage (using SSJS) is not too difficult, especially if you’ve done it before in LotusScript:

var doc:NotesDocument = database.createDocument();

doc.replaceItemValue("form", "Memo");
doc.replaceItemValue("sendTo", "mark@domain.com");
doc.replaceItemValue("subject", "hi there!");
doc.replaceItemValue("body", "content here");
doc.send();

It gets a bit more difficult though if you want to send out HTML mails. To create those you need to work with stuff like MIME entities, MIME headers and streams.

I’ve created a SSJS library that makes it easy to create HTML mails. It allows you to do the following:

To use the library you first need to add it to your application: create a new SSJS script library, call it xpHTMLMail and copy this code from the XSnippets site to it.

Next, in the code where you want to use it you can import that library by adding the following:

import xpHTMLMail;

To create a basic HTML message you write:

var mail = new HTMLMail();

mail.setTo( "john@domain.com" );
mail.setSubject( "Hi there!" );
mail.addHTML( "&lt;b&gt;Hi there!&lt;b&gt;" );<br clear="none" />mail.send();

You can add more HTML to the body of the email by making subsequent calls to the addHTML() function. The library also has methods to set the CC or BCC users:

mail.setCC( ["pete@domain.com", "mike@domain.com"] );
mail.setBB( "anna@domain.com" );

The setTo(), setCC() and setBCC() methods accept a string or array of strings.

The class has two methods to add attachments to a message: you can add them either from a document in the current application or from a file on the server.

1. To add a file from a document you need to specify the document’s unid and file name:

mail.addDocAttachment("5203C670815BC8C4C12579270029C543", "jellyfish.jpg");

Note that files from documents are read directly from the document into a stream and added as a MIME entity to the message. The files aren’t extracted first.

2. To add a file that’s store somewhere on the server’s filesystem you need to specify its path and file name:

mail.addFileAttachment( "c:/temp/", "report.pdf");

The sender of the message can be changed by using the setSender() method. You have to specify an e-mail address and can optionally specify a name:

setSender("user@domain.com");

or

setSender("user@domain.com", "Some User");