More and more XPage developers are turning to stackoverflow to seek community assistance with questions they have about developing XPage applications. This ongoing series will provide additional commentary and insights into the answers I have provided on the site that members of the community have found to be useful.
The short version of the answer is: yes, but barely.
@Functions in SSJS are not true @Functions the way we're used to thinking of them. In Notes client apps and non-XPage Domino web apps, @Functions are part of Notes Formula, a limited scope, highly optimized macro language. Execution of these functions occurs very "close to the metal", so to speak, so event code written in this language will execute very rapidly (assuming no other factors are at play, such as network lag when executing functions that trigger network transactions, logical flaws in the code that cause unnecessary complexity, and so on).
In SSJS, however, @Functions are simply... more SSJS. They're implemented in Java, but in order for that Java to run, the XPage runtime first needs to find the correct code to execute.
When an XPage application is built (in the Eclipse project sense of the term "build"... in other words, compiled), a Java class is generated behind the scenes by Designer. This Java class is stored inside a design note within the application. Hence, when the end user accesses an XPage design element, Domino isn't looking at the XML; it's running the Java class that was generated by Designer. The XML is just an instruction set that tells Designer what Java to generate. This provides a runtime performance benefit compared to, for example, the way browsers work: HTML markup is downloaded from the request target, the markup is parsed, and then the browser decides what to do in real time based on the result of parsing that markup. The advance compilation step undertaken by Designer allows the XPage runtime engine to follow a far more efficient process.
Practically every XPage contains at least one instance of Expression Language (EL). When viewing the XML source, you can easily spot instances of EL because it uses a recognizable syntax:
These expressions are occasionally also referred to as "bindings", because they are supported in two contexts: value bindings and method bindings. Method bindings are typically only used to define the code that should be invoked when an event is triggered; all other EL expressions are treated as value bindings. This simply means that the value of the component property that is bound to one (or more) of these expressions is not hard-coded. Some (usually, all) of the property value is calculated contextually at runtime.
Two portions of the EL syntax always have a direct impact on performance. The first is the initial character, which will either be a $ or a #. A $ indicates that the expression will only be evaluated once; expressions preceded by a # will be evaluated repeatedly. For Notes / Domino veterans, this distinction bears some loose conceptual similarities to the distinction between computed fields and computed-when-composed. In practice, each component property that can be assigned a value binding (and very few cannot) either does have a value binding or it has a "local value". Whenever any of these properties is accessed, the "getter" checks the local value first; if that value is not null, the value is immediately returned. Otherwise, it looks for a value binding associated with that property. If one exists, it returns the result of the evaluation of that value binding. Finally, if the property has neither a local value nor a value binding, null is returned.
Paul Withers posted a detailed explanation of the difference between the actual inner workings of $ / # value bindings. To sum up that explanation:
When a component is created, all properties defined on the XPage for that component are set immediately.
If the value is hardcoded, that value is simply passed directly to the property.
If, instead, it is a value binding, it follows one of two paths:
If a # binding, a ValueBinding object is created and associated with the property.
If a $ binding, the expression is evaluated immediately, and the resulting value is passed directly to the property.
That final bullet is why $ expressions are only evaluated once: by the time the component has been added to the tree, the property no longer has a value binding. It has a local value that is the result of evaluating a value binding. In case you're curious, this is also the reason why $ bindings are so sensitive to timing and sequence. # bindings aren't evaluated until the associated property is accessed; $ bindings are evaluted when the component is created. Hence, you can't refer in the property of a component at the top of the page to properties of a component at the bottom of the page: the component to which the value binding refers doesn't even exist at the time the value binding is evaluated.
This entire process is actually very easy to understand just by thinking in terms of spoken language. Imagine you've hired an employee, but every instruction you provide them and every question you ask them must be delivered through an interpreter, because you don't know their language, and they don't know yours. At all. Every time you say anything, even "yes" or "no", your employee does not understand until the interpreter has repeated what you said in their native language. If your interpreter is very skilled, they will be able to convey precisely what you mean, because they'll know which figures of speech have a specific cultural connotation and cannot simply be translated word-for-word. But every time you use some colloquialism that doesn't directly translate, extra care must be exercized to ensure your employee doesn't end up doing something drastically different from what you intended. And no matter how simple each unit of communication, it takes at least a little bit longer because it has to be repeated in a different language.
The moral of the story, then, is that when you write your code directly in Java, your XPages don't have to "guess" what Java should be executed... it just executes yours. Otherwise it's translating the code you wrote into a completely different language before it can run, and your user has to wait for that to happen. That wait is typically measured in milliseconds per expression, but add enough expressions and enough users, and they'll notice a difference.
locating XPage components with XspQuery
Sun, Apr 14th 2013 12:00a Tim Tripcony Several years ago, I wrote a utility Java class designed to make it easy to search for components within the current XPage instance based on various criteria. I've found it enormously useful, and, apparently, so has Keith Strickland, because he added it to org.openntf.xsp.extlib, complete with a few refinements. As an example of how you might use this, examine the following line of code:
List requiredFields = new XspQuery()
.loc [read] Keywords: ldd
your how is not your what
Wed, Apr 3rd 2013 11:36a Tim Tripcony I've noticed a pattern emerging when I'm asked for help with XPages. Here's a representative conversation:
"I'm trying to do [X] and it's not working. How can I do that?"
"What are you trying to accomplish?"
"I already told you. I'm trying to do [X]."
"No, that's how you're trying to do it. What are you trying to do?"
For example, replace "[X]" with "reach into a repeat control from outside it" (since this has become the most frequent topic I'm asked about [read] Keywords: xpages application
my new favorite quote
Sat, Mar 23rd 2013 5:20p Tim Tripcony "We go about our daily lives understanding almost nothing of the world. We give little thought to the machinery that generates the sunlight that makes life possible, to the gravity that glues us to an earth that would otherwise send us spinning off into space, or the atoms of which we are made and on whose stability we fundamentally depend. Except for children (who don’t know enough not to ask the important questions), few of us spend much time wondering why nature is the way it is; where the [read] Keywords: wiki
Taking the scary out of Java in XPages: Prologue
Tue, Feb 26th 2013 9:50p Tim Tripcony The discussion following my last post made stark the need for greater availability of information that makes the nature of Java more accessible to Domino developers. Credit for the title of this post goes to Declan, who is considering writing a series of blog posts on this topic. I will be doing the same; hopefully there will be a fair amount of duplication. As David Leedy is fond of stating, it's a good thing when several people share the same information, because that makes it easier for the [read] Keywords: domino
Passthru vs. component - my perspective
Sat, Feb 16th 2013 9:40p Tim Tripcony Paul Withers posted a thorough article explaining the differences between namespaced XPage components (e.g. ) and their corresponding passthru elements (e.g. ), providing numerous examples of what actually happens when these objects are constructed. I've always heard (and often repeated) that passthru elements are more efficiently processed than their namespaced equivalents, so Paul's post inspired me to offer my own perspective.
Simply put, there's practically no difference... but there a [read] Keywords: acl