XPages Gut Check

I got some bad XPages news today… where I’m doing something that works today… that I feel I should be able to do.. it’s not really that fancy.. but learned that it’s very possible that what I’m doing might not work in the future. šŸ™

Here’s the issue. If you look at this XPage from

You’ll see a list of contacts in a repeat control. Yes this is an UGLY page. But the inside of the repeat is being generated from a SSJS Object. Why? I wanted to seperate my data from the UI structure. I’ve included that code at the bottom of this post.

What’s a SSJS Object? We’ll I’m just a small town Notes Client Developer at heart. But there is a way to use SSJS similar to a LotusScript Custom Class. I like that. It’s “comfy”. So my SSJS Object can basically have properties and methods/functions.

I demonstrated this technique in my Introduction to XPages Video (Part 2). Skip to minute 42ish to see what I’m talking about.

Anyway – what I’ve learned today.. is that this type of object – which works totally fine in sessionScope today… does not work in viewScope. (I’ve not ever tried that actually). In addition I learned that it’s very possible that this technique will no longer work in sessionScope in the future.

Why? I don’t know. It has to do with “Serialization”. Honestly I don’t know what that means. viewScope is strict about this.. sessionScope “overlooks” this… for now.

The best solution is to “Suck it up, Learn Java and use Managed Beans”. And while I agree that is the best way to go, I feel a little bummed that I’m forced to go the Java path and that SSJS can’t handle something that LotusScript did so very well.

Anyway… this might not be a huge deal.. I don’t know.. Maybe I’m the only one really trying to do this. I am certainly not the best XPages/JavaScript dev in the land. Far from it actually. I just liked learning and working with SSJS in a similar way that I used LotusScript. It helped me with the transition.

I will say that I did reach out to someone from IBM, and very quickly got a nice response giving me details on this and even a potential workaround. I’ve not fully digested that information yet, but I very much appreciate the IBMers that took the time to get involved!

I’ll be playing with this stuff this weekend, but I think the moral is that XPages development, unfortunately, needs more Java skills then I originally thought, and more then I would have wanted. šŸ™

Here is the code structure of the SSJS object:

var contactDoc = (function contactDoc(key) {

// Key really needs to be a string here. Convert it before it gets passed in.

//Pull data from External Datbase
// Here are the Database and View Names
var dbName = “FakeNames.nsf”;
var viewName = “ByName”;
// I assume that the database we’re looking up is in the SAME PATH as the current db
var path = database.getFilePath().split(database.getFileName())[0];
var fullDB = path + dbName
var lookupDB:NotesDatabase = session.getDatabase(database.getServer() , fullDB);
//var vLookup:NotesView = lookupDB.getView(viewName);

//print(“key=” + key);

var size = @Length(key)

if (size > 15)
//This is a Unid
var unid = key;
var contactDoc:NotesDocument = lookupDB.getDocumentByUNID(unid);
var contactKey = contactDoc.getItemValueString(“number”);

var temp = 1
var status = true
else if (size>1 && size <= 15)

// Key must be an @Unique or ProjectKey
var lookup:NotesView = lookupDB.getView(“ByNumber”);
// print(lookup.getSelectionFormula());
var contactDoc:NotesDocument = lookup.getDocumentByKey(key, true);
var unid = contactDoc.getUniversalID();
var contactKey = contactDoc.getItemValueString(“number”);
var status = true
var temp = 2
var status = false
var contactKey = “”
var temp = 3

return {
getUNID: function() {
return unid;
getKey: function() {
return contactKey;
getFirstName: function() {
return contactDoc.getItemValueString(“firstname”);
getLastName: function() {
return contactDoc.getItemValueString(“lastname”);
getFullName: function() {
return this.getFirstName() + ” ” + this.getLastName();