As developers get more comfortable with XPages, one of the steps is to start to using the Compute on Page Load option instead of the Compute Dynamically option for Server-Side JavaScript. But there are times when that can’t be done. I encountered this last week and it took a chat with Jeremy Hodge for me to understand my problem. One of my colleagues had the same problem yesterday. And Sven Hasselbach has blogged about the same issue today. Unfortunately, it’s not a bug. It’s a fact of life and one also found in JSF.

 

Sven encountered the issue, as did I, in an Output Script control. Basically, if your Output Script code combine ${…} code and #{…} code, for example #{id:myField1}, the #{…} code is always evaluated at page load. This means, in the case of #{id:myField1} that it returns a blank ID. This isn’t limited to Output Script controls. It’s the same for any control, even a Computed Field.

 

One of the nice things about XPages, once you’ve mastered the basics, is the Custom language. This allows you to combine textual and computed elements in a single Value Binding, as I blogged about last July. But even in a Computed Field, you can’t combine ${…} and #{…}. Let’s put this in context.

 

Look at this code. It’s fairly basic. We’re outputting a username and control IDs.

But look at the output. For the first control, we get the ID. For the second, we get the username, but not the ID.

That’s because the ID for computedField1 has been generated at runtime, but the binding for computedField2 has been generated at page load. Basically, because we have something that needs generating at page load, everything needs running at page load.

 

This may seem strange. But if we understand what’s happening behind the scenes, it’s understandable. Any non-literal string is stored as a String and passed to a Java function. So whereas a developer might consider “${javascript:@UserName()}” as a distinct element, the XSP Command Manager just interprets the whole value property as something that needs passing to a Java method. Let’s look at the Java code outputted, and the difference becomes apparent.

 

The first control has the following Java code:

The whole value property, including the #{id:…} element is stored into a String , which is passed as a parameter to evaluator.createValueBinding() – not all parameters passed to the method are shown.

 

But compare computedField2′s Java code.

Here, again, the whole value property including the @UserName element is passed into a String. But notice it is passed in as #{…}. The ${…} serves only to tell Designer that it needs to call evaluator.getBindingValue() instead of evaluator.createValueBinding(). Because the value property is passed as a String parameter of a method, everything must use createValueBinding() or everything must use getBindingValue(). You cannot combine both, nor do I expect that you ever will.

 

Someone more knowledgeable in the intricacies of JSF can probably explain this  better than me. But the key to remember is to use #{…} or ${…}, but not both.

12 Comments for this entry

3 Trackbacks / Pingbacks for this entry