Yellow is the New Blog

In response to: XPages... the Biggest Barrier

Unless you're nothing whatsoever like me, once you start actually developing XPages, you'll never want to write LotusScript again. I know that must sound crazy coming from me... until October I was a LotusScript fanatic. But trust me, SSJS is every bit as easy to write as LS (in my opinion, even easier, for several reasons), but WAY more powerful. I admit, thus far I've had the luxury of developing XPages for audiences primarily interested in a web interface. Additionally, nearly all of the XPage-based apps I've been building have been brand new applications. But on one recent project the client was rewriting an entire public-facing website from a LS-heavy version to an XPage version; much of the LS code that was still needed could be rewritten at a pace of 5-10 minutes per agent because the method syntax is so similar... but the majority of the code wasn't even needed anymore because it was reams of script just for rendering interface components that are now bundled controls in XPages.

There are ways to save yourself time now:

1. Use lower-camel-case. For example:

Set docSomething = vwSomething.getDocumentByKey("key", True)

When it comes time to rewrite that line of code in SSJS, all you have to do is delete "Set" and change "True" to "true" (and - optionally, but recommended - tack a ; onto the end of the line). LS won't let you change the case of a Boolean constant, but it doesn't care about case in method calls. So make your code more portable by using lower-camel.

2. Avoid extended class syntax for accessing item values. For example:

subject = docSomething.subject(0) 'original LotusScript

...becomes:

subject = docSomething.getItemValueString( "Subject" ); // SSJS equivalent

If your code is already:

subject = docSomething.getItemValue( "Subject" )(0)

...your code is more portable, because (like the previous example) there's simply less changes required.

In short, when there's something optional in one language that's required in another, it's generally a good idea to adopt that as a convention, because sooner or later you'll have a reason for using the other language... at which point either you're completely rewriting your code in a syntax that seems utterly foreign... or you're just tweaking code in a new but already familiar context.