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 xpagescheatsheet.com:
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)
//print(size);
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”);
//print(key);
var status = true
var temp = 2
}
else
{
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();
}
}
});