Writing a single library for SSJS and CSJS validation – first success

The other day I wrote about my failure to realize that CSJS and SSJS libraries shalt not cross  during my attempt to write a single library for CSJS and SSJS validation code.

Not to be out done and with some great suggestions from the wonderful Sven Hasselbach I trucked on into the next attempt.

Parameterized development

I first met this concept a few years ago. I was working on an application created by John McCann, and all the script routines for a suite of applications were sorted in notes documents. The application would look up the code it needed and then executed it as needed. This made for extremely efficient code management and the ability to make updates to code snippets without changing any “code”.

Using this design pattern I set out to create a simple document in a view with a simple JavaScript function within it – the “are the fields the same” code I used in the previous article.


I then created a Java Bean to access the notes view and get the field value.

(Yes I could have done it in SSJS – but hey this is a learning exercise as much as anything and the more Java code crosses my path (as rare as it is) the more likely I am to get familiar with it)

The bean is pretty simple and I am not going to detail the how’s and why’s and when’s of the bean – if you want to learn more about beans go see Russ Maher !!

package com.xomino.jsLookup;
//load import for Domino classes
import java.io.Serializable;

import lotus.domino.*;
import lotus.domino.local.Database;
import lotus.domino.local.Document;
//import for JavaServer Faces classes
import javax.faces.context.FacesContext;
//var marky = com.xomino.jsLookup.getValidationCode.getCode
public class getValidationCode implements Serializable{

	private static final long serialVersionUID = 1L;
	private String theCode;

	public getValidationCode() {
		System.out.println("Starting Bean");

	// open method, this actually runs the whole App
	  public String getCode(){
	      System.out.println("MARKY SSJS");
	        // let's add a try catch here, to grab errors near the end
		    try {
		      // Declare Variables, one to hold Documents/ and page through results with the other
		      Document doc;
		      //BEGIN DEBUG
		      Database database = (Database) FacesContext.getCurrentInstance().getApplication()
		      				.getVariableResolver().resolveVariable(FacesContext.getCurrentInstance(), "database");
		      System.out.println("Database Obtained..." + database);
		      // Find the view in question
		      View view = database.getView("jsValidation");
		      System.out.println("View Obtained..." + view);
		        //get the document
		        doc = (Document) view.getFirstDocument();
		        System.out.println("Doc Obtained..." + doc);
		        System.out.println("Loading to Xpage...");
		        // process the document in the View
		        //recycle to free up mem
		        theCode = doc.getItemValueString("js");
		        System.out.println("Loading to Xpage...");
		    } catch (Exception e) {
			return theCode;


Big thanks to the Java Guru known as David Leedy for pointing out my inability to watch notesin9 videos correctly and learn how to do beans

Anyway the interesting code

The code which is stored in the notes document is just a simple JavaScript function

function checkPasswords(){
    if (getComponent("Password").getSubmittedValue() != getComponent("ConfirmPassword").getSubmittedValue()){
      return false;
    } else {
      return true;

Back in my XPage I set up two sections for code – one for SSJS and one for CSJS

The CSJS code which will run on the web page looks like this (return lookupCode.getCode())

	<xp:script clientSide="true">
				return lookupCode.getCode()
	<xp:script src="/libValidation.js" clientSide="true"></xp:script>

In this context the text string returned from the bean feeds directly into the contents of the script library – looks like this in the page source:


The keen eyed among you will have noticed I also included the libValidation.js function which I created in the last article which is the CSJS equivalent of the getComponent(x).getSubmittedValue()

The SSJS code is similar but with one crucial difference:

<xp:validateExpression message="Passwords Must Match"><!-- (2) -->
			var theCode = lookupCode.getCode()
			return checkPasswords()

In the SSJS I have to use “eval” to evaluate the text string which is returned from the bean. This works just fine – but eval is very very evil and I do not like this approach at all. But right now we are talking proof of concept so I am ok with it in development but would never use this in production. If the contents of the lookup document were compromised this would expose a massive hole in the security of the entire server – but that is a blog post for another day……

But the same code (lookupCode.getCode()) was used to get the code and if you notice checkPasswords() is then called in this context to test if the fields are the same.

Running this through a browser (with no CSJS yet) we can see a successful test


Then the CSJS is called from the onClick event of the submit button

<xp:button value="Submit" id="button1">
  <xp:eventHandler event="onclick" submit="true" refreshMode="complete" immediate="false" save="true">
      if (!checkPasswords()){
        alert('passwords must match')
        return false

Which looks like this


So why are we doing this again Marky?

Well the point is that CSJS alone is a better experience for the user but it is not secure – so if we can write the validation code once it can be used Client Side and Server Side with the minimum of duplication

Here is how I break the CSJS validation and bypass it – see in firefox – I can override the checkPasswords function to show a different prompt and then return true – submitting the form


Which is then validated using the SSJS – securing the application 🙂



In both cases we were able to use the checkPasswords() function which was written once and stored in the notes document So as far as I know this is the first example of using the same JavaScript code to validate a form client-side and server-side – which was the initial goal – there is some improvement to be done here though I am sure


And there are a few…..

  1. For the uninitiated the eval function is evil and should not be used in production code unless you can absolutely guarantee  the security of the source.
  2. Looking up the code in a document has an overhead and this would not scale well over many functions and many documents
  3. There is a lot more code written to save copying and pasting a few lines of code in this case – this did not make my life in any way shape or form easier
  4. There has to be a better way – and the quest has only just begun

EXTJS in XPages #10 – Grid Row Expander plugin

In this article I will demonstrate how to add expandable and collapsible sections to each grid row using the extjs rowexpander plugin.

EXTJS in XPages series

Here are links to all of the previous articles in this series


The EXTJS in XPages demonstration database can be found at http://demo.xomino.com/xomino/Extjs.nsf/xGridExpand.xsp


The sample database that will accompany this series is  available from the menu in the live demo database from this link – http://demo.xomino.com/xomino/Extjs.nsf


Now we have the basics of how to build a grid down I am going to demonstrate some of the cool plugins and features which can be added to the EXTJS grids within our XPages. This article focus on the “rowexpander” plugin which gives us the ability to “expand the row” and format the displayed output.

In the example I have created I have used a normal grid showing 240+ countries and territories in the world. When you click on the row it expands and show the reformatted data fields and the country’s flag.


How does it work?

There are no new code bases to be loaded for this plugin it is “out of the box” so to speak. It really could not be simpler…..

I created a new view “vwCountry” and a new REST service to pump out the data

<xe:restService id="country" pathInfo="country">
		<xe:viewJsonService defaultColumns="true" viewName="vwCountry" count="10000"></xe:viewJsonService>

And then the grid code to retrieve it is the same as the the bufferedRendered example (with new field names)

The significant part is adding the plugin to the grid and inserting the rendering code – but that is also copy and pastable almost. As you can see from the code below there is a ptype: rowexpander plugin and then within that I use an EXT.XTemplate to show the code which I want to display on the screen while the row is expanded. It is as simple as that.

    var grid = Ext.create('Ext.grid.Panel', {
        renderTo: 'gridHere',
        frame: true,
        height: 400,
        layout: 'fit',
        title: 'Countries',
        plugins: [{
            ptype: 'rowexpander',
            rowBodyTpl : new Ext.XTemplate(
                '<p><b>Country:</b> {Name}</p>',
                '<p><b>Life Expectancy:</b> {Life}</p><br>',
                '<p><b>Highest Peak:</b> {HighestPeak}</p>',
                '<p><img class="flag" src="http://www.worldatlas.com/webimage/flags/countrys/zzzflags/{CountryCode:this.lowerCase}large.gif"/></p>',
            	lowerCase: function(cc){
            		return cc.toLowerCase()

Once again this shows how quick and simple it is to provide excellent functionality for your users with little to no effort on your part as the developer – and that is really what we all like 🙂

Side note
Originally I used the buffereredRenderer on this grid but there appears to be a display issue (v4.2) which has been reported and tracked with Sencha. I removed the bufferedRenderer and it worked fine.

Someone is having a laugh right?

I got this in my email today – trying to help a friend out

See if you can spot scary………..


Role: Lotus Notes Developer

 Location: CHICAGO, IL

Duration: 6+ months


Skillet required:

 Experience using and developing applications for Lotus Notes Version 8 Experience using and developing Domino web applications

 Knowledge & experience in Lotus Notes Administration processes

5+ Years experience developing Lotus Notes client applications

Proficiency with the Lotus Notes security model (ACL, ReaderNames, AuthorNames, Domino Directory, etc)

Proficiency with Lotusscript Programming Language

Proficiency with Lotus Notes Formula Language

Great communication & documentation skills

Some knowledge/exposure to Microsoft Excel/Powerpoint

Willing to be available to work 24/7

 Willing to violate US labor & tax laws by working many hours of overtime with no pay

Knowledge of Hindi language would be strategically beneficial


If you are interested in this position please respond to me with your resume with following details

Full name :

Visa status :

Contact number :

Best time to reach :

Current location :

Best rate (per hr on w2):


Google Chrome 27 – now with added voice searching

The new Chrome v27 went live today with a new voice search capability using the HTML5 media capabilities the browser asks to use my microphone and when it does it allows you to speak your query rather than type it.

It is similar to the capability which has been in Android Jelly Bean 4.2 for a while now which I find very useful and I am becoming more reliant on it – we still have some accent issue to get over though.

Below is a quick video demonstrating that it still has some hurdles to get over and some interesting results 🙂

Kinda my point in highlighting this is really to illustrate the HTML5 media capabilities and where the browser is going. The ability to turn speech into text is not new – but to integrate it with our web applications is…

Writing a single library for SSJS and CSJS validation – failed attempt #1

In this article I will demonstrate my first futile attempt to consolidate CSJS and SSJS libraries so that we only have to write validation once. I will also discuss JavaScripts Closures which unless you have already encountered them will make your head hurt thinking about it 🙂


I was reminded in one of the comments on my blog last week about how it is still a pain in the butt to have to write client side JavaScript validation (to provide a good user interface) and server side JavaScript validation (to ensure data integrity and because CSJS validation is easy to break). So I set out to try and simplify this process by trying to copy a basic SSJS JavaScript validation routine in CSJS. I figured if the average XPage developer is now used to writing validation in SSJS then why confuse things. Try and mimic the basic functionality client side and away we go – simple right?

Comparing two fields in SSJS

So here is my basic example – comparing two password fields which have been submitted

<xp:validateExpression message="Passwords Must Match">
        if (getComponent("Password").getSubmittedValue() != getComponent("ConfirmPassword").getSubmittedValue())
            return false;
          } else {
            return true;

Here’s my form in Firefox – the Password field is the one we are going to look at in the examples. I want to test if the Password and ConfirmPassword fields have the same value – in the client and on the server. The above code does it on the server. (originally posted here)


So the trick is to try and mimic getComponent(“Password”).getSubmittedValue() in client side JavaScript and then the code which is already written can serve to validate on the client side as well – well that is the plan anyway.

Not as simple as you’d have thought

So I started by learning about how to chain JavaScript functions and would you believe it is rather mind-bendingly simple and yet amazing complex to get your head around at the same time.




But the basic premise it to be able to “return this” from the original function which therefore returns a function – which means you can then .doSomething to it.

First – Prototypal inheritance

A cool part of the JavaScript language is that you can create prototype (copy) of an object and it inherits all the traits of the originator – the problem I ran into with this is that you have to create a object in the first place to then chain the function to it – that did not mimic the exact syntax I was looking for – maybe another day. (example from this website)

function Pet(name, species){
  this.name = name;
  this.species = species;
function view(){
  return this.name + " is a " + this.species + "!";
Pet.prototype.view = view;
var pet1 = new Pet('Gabriella', 'Dog');
alert(pet1.view()); //Outputs "Gabriella is a Dog!"

Then closures

OK for those of you who do not understand JavaScript closures:

  1. Join the club
  2. Sit down with a good cup of tea and a blanket
  3. This is going to hurt

As far as I understand it (and it would not be the first time I was wrong) – a JavaScript closure is basically a function within a function which has access to the locally scoped variables after the function has returned.

In the spirit of Hammer Horror films – a closure is a function within a function which can live on after the original function is finished. It can then feed off the innards of the function which is now dead – nice!

Told you your head would hurt – go read this, it might help http://www.crockford.com/javascript/private.html

So I created the getComponent function like this

var getComponent
getComponent = function(key){
    var temp = dojo.query('[id$=:'+key+']')[0].value
    return this

And when I run that you can see we get the value from the field logged and then “window” returned which is the namespace for the functions

Within the getComponent function I then added the getSubmittedValue()


Without the need for the console.log – we now get “Marky” returned

How does that work then? You’re right my head hurts……

Yeah me too !

  1. We saw the getComponent function on its own created the temp value and returned itself (making it chainable)
  2. The getSubmittedValue function was then called within the getSubmitted function
  3. getSubmittedValue does not have a parameter passed to it through the originating call
  4. But because it is a closure it does have access to the temp variable which was created when the original getComponent function was called
  5. uuurgh *shakes head*
  6. So anyway it works and woooooo – I got what I wanted !!!
  7. WHY do closures work like this? I haven’t figure that out yet. I think it is cos in this case the getSubmitted function is still in memory even though it has been “completed” it still exists and can therefore still be “used” – but that is just a  guess on my part.

This then allows be to create a generic checkPasswords function which should run with the same “JavaScript” for client side or server side – man I was dancing around the room after spending the entire week trying to figure this out 🙂

var getComponent
getComponent = function(key){
    var temp = dojo.query('[id$=:'+key+']')[0].value
    getSubmittedValue = function(){
        return temp
    return this

function checkPasswords(){
	if (getComponent("Password").getSubmittedValue() != getComponent("ConfirmPassword").getSubmittedValue()){
      return false;
    } else {
      return true;


Then I tried to implement it in my XPage – and got the face palm moment – ServerSide JavaScript Libraries and Client Side JavaScript libraries are discrete and nether the two shall cross…..

You cannot include an SSJS library on your “web page” and you cannot include a CSJS library in your Server Side code



So there’s my fail – but even after elation and then facepalm I am not down about this at all.

I am actually very happy about how much I heave learned about JavaScript this week – I have always considered myself “ok” at JavaScript but never advanced enough to start to write it as a “JavaScript developer”. I think that path has started and I am going to be writing about it I am sure.

If anyone has any suggestions or insight on how I can possibly move this forward please let me know. I would love to be able to create a single method for doing SSJS and CSJS validation without the need for duplicative coding.


XPages ND9 (Dojo 1.8) does not work with other AMD loaders (and the work around)

Today I took a new jQuery plugin that I was playing with from an R8.5.3 environment where it worked, to an R9 environment and it failed – I figured it had something to do with something I had been reading about over the last month and in fixing my problem this lead to a more serious realization that I KNOW other people are also going to come across.


A brief scan of the last month’s discussions on Xpages and jQuery Mobile 1.3 reveals a number of posts started by Dave Leedy regarding the use of IBM Notes Domino 9 and jQuery Mobile 1.3





What’s going on?

I saw the following Tip from Sven Hasselbach (very smart man!) on Dave Leedy’s blog post

Looks like an AMD loader problem with Dojo & JQM. I have tried out to disable the Factory scan in a test page and this worked for me. To do this I have added the following parameters in the xsp.properties:

xsp.client.script.dojo.djConfig=dojo-amd-factory-scan: false

Maybe this can help you with your problems in ND9.

This lead me to this bug report


make dojo work with other AMD loaders

Which then lead me to the realization that this is a bigger issue than just JQM 1.3 and I solved my problem and here is how.

Solution (ND9)

Within the Package Explorer  (Window—open perspective –> xpages) in the WebContent folder for your database you will find the xsp.properties file (as described http://heidloff.net/home.nsf/dx/06172011015521AMNHE8Y7.htm)


Click to open the Source Tab

and enter the following

xsp.client.script.dojo.djConfig=dojo-amd-factory-scan: false

And Save – that’s it


If you look at the source code of the created XPage you will see that the new parameter has been added to the script tab creating the dojo.js as a djConfig property


doing a quick search explains what this property does


“For example, we could disable the amd factory scan (scanning the module for CommonJS require(module) statements to load as deps) with…”

Not only does that solve the problem with jQuery Mobile, it also solved my problem with the jQuery Table plugin which I wanted to use, which used require.js to load the jQuery dataTable plugin.


thank you Sven Hasselbach (again!)