I was recently asked by a colleague whether a partial refresh event can be canceled during its execution - if, in other words, the code first checks whether the rest of the code is necessary or useful, and that check returns false, can the code then somehow prevent the refresh from occurring?
There is, however, a way to achieve the same result, and to do so even more efficiently: split the code execution into two distinct operations. To be precise, completely isolate the portion of the code that does what the event itself is intended to do from the portion that determines whether that action is even appropriate under the current circumstances.
All XPage components support a "rendered" attribute. If this attribute's value evaluates to a false Boolean result, the server will not send any representation of that component or its descendants (if any) to the request consumer. In the most common use case scenario, this means that, if a typical browser accesses a typical XPage, and that XPage includes a component that is not to be rendered, the HTML that would otherwise represent that component is never sent to the browser. The component still "exists" as part of the component tree for that page, so (all else being equal) its remaining attributes are still calculated during each request, and other components can examine its attributes if needed, but the user never sees that component... only any effects it may have on other components.
Because this concept is so similar to the notion of "hide-when" formulae in traditional Domino applications, this is once of the first concepts learned by an XPage developer, and is therefore almost universally known. What is arguably less known is that event handlers are actually components too. They have no visual representation in the HTML, but HTML is, in fact, sent: specifically, a single script tag typically encompasses a representation of all event handlers defined within the tree... a representation which consists of code that causes the browser to listen for each defined event.
So, to sum up, if some of your events are only applicable under certain circumstances, but you want the component to which the event is bound to display anyway, set the rendered attribute of the event handler itself to a value binding that calculates whether the event should fire, and set the event itself to just do whatever it should do if the event does fire. With this simple change, you can prevent any network traffic or server processing when the user clicks something that would not produce a useful result... just be sure to give them some visual indication that nothing is going to happen (e.g. link the component's styleClass to the same logic, causing the component to visually indicate that it is "disabled").
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