Now that XPages are set to take over the world, did you think your Lotuscript skills were wasted? The short answer is absolutely not. As you can see from this image (taken from another fantastic XPages example by John Mackey), there's something funny going on here. This looks an awful lot like Lotuscript.
It isn't really Lotusscript, but instead it's JavaScript with objects created to do most of the same things you can do with both Formula languages.
Most people who program in Lotuscript mix up two distinct aspects of the language. The syntax and keywords of the language itself, and the back end object model that you use it with. They're actually two entirely distinct things. The back end object model you're used to is where you've spent most of your time getting comfortable with doing things. Most of that skill and comfort transition to XPages easily because most of that object model is right there at your fingertips.
The syntax will more closely match the back end object implementation in Java, if you're familiar with that, but the differences are fairly minor. Take a look at what's going on here.
You're seeing the Lotus back end objects -- just like you use them in Lotuscript -- being used as part of the design on an XPage for the web. This isn't in a webQuerySave agent or anything, its right on the page as part of the event for an object on the page.
Something else you should notice -- look in the top left of the picture. Notice it says "(Server Side)"? That's where much of the truly sick power of XPages comes from. I'll write more on that later.
Comment Entry |
Please wait while your document is saved.
including them in LotusScript even though it doesn't force us to.
2 - Case will matter. doc.GetItemValueString != doc.getItemValueString...
LotusScript doesn't care, but JavaScript definitely does.
3 - Semicolons. Strictly speaking, JavaScript doesn't require that each line
end with one (because it's hoping the browser can guess where they should have
been included), but if this is all getting parsed by Java on the server, it
probably will break if a semicolon is omitted.
Folks that have spent a sizable amount of time coding Java in Domino by the
time 8.5 is released will already have all of these habits, because the
compiler will have forced them to conform to each, so transitioning into using
that syntax in JavaScript will be much easier.