Yellow is the New Blog

In response to: XPages - The Good, The Bad and the UGLY - II

I'm gonna have to disagree with both of you. JavaScript doesn't need classes because of closures... if you don't know what closures are, now would be an excellent time to find out. Nathan's spot on about Squawk: there's maybe a dozen lines of SSJS; and in every case it's just instantiating a Java object and calling a couple of its methods. But to be honest, all the apps I'm writing now include less and less custom Java classes because I'm sprinkling in calls to standard Java classes where I need them (same goes for @Functions, though that too is decreasing), and everything else is being handled in typical JS syntax. It's a very misunderstood language... far more powerful than its reputation (which is primarily the fault of lazy developers). Expect a followup post on my blog about what a JS "class" looks like. :)

If you follow Declan's blog, you already know that using the OneUI CSS template makes it even easier to rapidly give your XPages a pleasant user interface. Here's a quick tip for adding an interesting UI element to your pages that takes advantage of some of the OneUI behavior.

When you wrap any link in a span that has a style class of "lotusBtn", the link is rendered with a border and background graphic, so it looks like a button even though it's just a link. This is one approach for ensuring that an element intended to behave like a button (in other words, has an onClick event) will render similarly across all browsers. Since a section control, when rendered in a browser, is nothing more than just a link that uses client-side JavaScript to toggle the display of additional content, this allows us to render the section header such that it appears to be a button that, when clicked, displays the section contents. Since the entire section is wrapped in the "lotusBtn" span, which has a 1px border, the entire section has a border, but only the header has the background graphic... in other words, it looks like an inline dialog.

For example, if your XPage includes functionality for parsing RSS/Atom feeds and you want to allow the user to submit the URL of a feed they want to subscribe to, you might create a table for the URL field and corresponding label, and a button (or link styled as a button) for submitting the value. Here's how that would look if using this style technique.

Collapsed:

Expanded:

Note that in this case I'm using a custom image for both the expanded and collapsed state.

So the user clicks an element that looks like a button, which displays the additional detail inline instead of as a modal dialog or popup window. To enable this in your own XPage, select the section you want to render this way, switch to the Source tab and wrap the xp:section element in the following markup:

<xp:span styleClass="lotusBtn"><xp:section....</xp:section></xp:span>

One more quick customization to this technique: in addition to the "lotusBtn" class, you can add either "lotusBtnAction" or "lotusBtnSpecial". Instead of a silver background with blue text, the section header will have white text on a green background if using "lotusBtnAction", or blue if using "lotusBtnSpecial". So, for example, for a white-on-green button, the source would look like this:

<xp:span styleClass="lotusBtn lotusBtnAction"><xp:section....</xp:section></xp:span>

Click here to see an example of all three styles in action.

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.