A little over two years ago I blogged about the different languages available in XPages, namely Expression Language, Server-Side JavaScript and Custom. I explained what Custom was and how it could be used.
Bearing in mind that XPages are compiled down to Java code, with each control being a class, it makes sense that the fewer controls you can use, the better for performance. Evidence bears out that hypothesis, as I will be showing at UKLUG next month. Furthermore, of the three, Server-Side JavaScript performs worst. Literal strings don’t need passing to a parser, and Expression Language is parsed quickly. I suspect it’s using something like a VariableResolver and PropertyResolver, to quickly access the datasource and call a getValue() method.
Consequently, it’s better to combine Expression Language and literal strings rather than use Server-Side JavaScript to concatenate the computed values and literal values. Used across lots of controls and particularly where latency is involved, this technique will perform better.
However, as with everything, there is a caveat. Not significant, but it did leave me scratching my head for a while. Out of simple habit I used Custom language to combine EL and literal strings in the url property of an Image control. Shortly thereafter I noticed that some Custom Controls were showing completely blank in the Design pane, even though there was plenty of content in the Source pane. If I was in the blank Design pane and clicked on another tab to, for example, open a different Custom Control, that tab was also blank. Eventually I tracked it back to that url property of the Image control. As soon as I computed that property as Server-Side JavaScript, the Design pane behaved as expected.
So the lesson to learn is to use the Custom language for performance, but not for the url property of Images. That has been the only property I’ve come across that has caused the Design pane to be blank.
Hi Paul,
Are you saying that when using this method it won’t show in the design pane, or it doesn’t work at all?
The code works fine, the application compiles without issues and displays fine in a browser. However, in Domino Designer when you open the Custom Control (or any that use it), the Design pane is completely blank, which gets a bit frustrating.
Hi Paul,
Can you compute the field name in the EL binding?
I’m trying to bind some editable address fields to a document, but I want the field name to be computed, as the fields are in a custom control where a property tells it which type of address to update.
If I use javascript to bind the field, it makes the fields computed, and I need them to be editable.
I’ve tried variations of the line of code below using EL, but it won’t accept it.
#{orgDoc.#{compositeData.addressType}AddressLine1}}
(where #{compositeData.addressType} could be “postal” to bind to the field postalAddressLine1).
Any help would be appreciated, thanks.
Binding editable fields is a bit different. Tim Tripcony has blogged on the topic http://xmage.gbs.com/blog.nsf/d6plinks/TTRY-86EMBS
There’s also a couple of questions covering this on StackOverflow (an excellent source for queries). This is the best starting point for both http://stackoverflow.com/questions/9913331/dynamic-data-binding
You need to use array notation instead of the dot notation. Alternatively, use SSJS computed on page load to return a runtime binding. In the example shown by Serdar, the output of the on page load SSJS (beginning $) returns a string that begins #{. So during runtime, those two letters tell the parser that the following bit is expression language, so it’s then parsed exactly the same as if you set value=”#{…}” explicitly in the source code.
yep that does it… thanks for you help : )