I'm a big fan of the JSON-RPC (a.k.a. "Remote Services") component from the XPages Extension Library. If you've ever asked, "how can I call server side JavaScript directly from client side JavaScript?", this component is the answer to that question. Not only does it make it incredibly easy to define a remote API for your client side JavaScript to interact with, it's also wicked fast.
One reason it's so efficient, however, is that it skips the standard view serialization. Remember, when I talk about views in relation to XPages, I'm almost always referring to the V in MVC, not the Domino index design element. In 8.5.2 and above, the default page persistence setting is to "keep pages on disk". When this option is selected (or left as the default), one of the last operations performed when a user accesses an XPage is serialization of the component tree hierarchy to the server's temporary folder on the local hard drive. Everything that the server knows about the page state - values of fields, properties of read-only components, etc. - gets flushed to flat files on disk, allowing the server to "forget" all of that... literally: once written to disk, it can be removed from memory.
If the user triggers some event against the rendered instance of that page, the request parameters sent to the server include enough information for it to locate that state information on its hard drive and parse it all back into memory. Assuming your server has post-millennial hardware, this all still typically happens in a matter of milliseconds, but there is an incremental lag caused by the disk I/O, which is the price paid for increased scalability; the alternative to this process is to hold all these page states in memory, so the more concurrent users you have, the sooner your RAM would vanish. If you've got enough RAM, of course, you can change the default behavior to an alternate option with more rapid response time. Changing it to "keep pages in memory", for example, forgoes serialization entirely. This causes events to fire more rapidly, because the server "remembers" the full page state (because it's still in RAM), so it doesn't have to go to disk to reconstitute the component tree prior to responding to the event. As a consequence, however, the state of all these pages lingers in memory long after each ceases to be needed.
The compromise setting is to "keep only the current page in memory". When this option is selected, the server only stores one component tree at a time for each user. When a user accesses a page, it renders the markup, but leaves the view state in RAM. Every event fired against that view instance is accessing that in-memory component tree state. As soon as the user navigates to another page, it serializes the previous page to disk, then constructs the new page in memory (and leaves it there until the next navigation event). If the navigation to a new page was not the result of leaving the page, but instead loading a different page in a new browser window (or tab), then it's conceivable that the user might close that new window and continue interacting with the original page. In this scenario, the server is then able to reconstitute the state of that page using the same process it would follow were it keeping all pages on disk. If, however, it was a typical navigation event (moving from one page to another within the same window), then the state of the first page will never be needed again. It's still there on disk, but will get automatically flushed once the user's session expires. In my opinion, this setting should be the default, because it provides excellent per-page performance without wasting RAM.
Because the default option is to keep all pages on disk, however, it is important to realize how this impacts the behavior of any JSON-RPC services you define. This type of service seems designed primarily for operations that are independent of component state. For example, I might wish to pass an employee's name or user ID from client side JavaScript and return a slew of details about that employee (job title, supervisor name, contact information, etc.). When any RPC method is called, the server needs to load the component hierarchy in order to know how to invoke the method, but there's no reason to save an updated instance of the component state once it's done so... we weren't posting new field values, or even running any events, just calling some remote code defined inside the XPage. So even if the method invoked has data impacts (e.g. send an email, close all tasks associated with the current document, etc.), it skips the serialization step entirely, because it assumes that no material changes have been made to the component state. And that's almost always an accurate assumption.
But what if it isn't? What if the behavior of your RPC method does alter the state of a component or values in a data source? If your application keeps the current page (or all pages) in memory, it doesn't matter, because whatever changes you're making are altering the in-memory view state, and any subsequent events will access that same in-memory state. But if you're using the default option to keep all pages on disk, because all RPC methods skip the step that saves the component state, your changes are lost... unless you force this serialization to occur anyway. The good news is that, while this might sound complex, it's quite easy.
In any RPC method that does make changes to component properties or data source values, at any point after all of those modifications are complete, add the following operation:
var app = facesContext.getApplication(); var stateManager = app.getStateManager(); stateManager.saveSerializedView(facesContext);
This forces the current view state to be written to disk, just as it would during a normal event. Ergo, any subsequent event is interacting with the page as you last left it, with any changes made by the RPC still intact.
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()
.addInstanceOf(UIInput.class)
.addEquals("required", true)
.loc [read] Keywords: ldd
lotus
dojo
java
javascript
openntf
oracle
server
389
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
xpages application
java
154
SSJS is a crutch
Fri, Feb 22nd 2013 10:50p Tim Tripcony I've been debating for quite a while whether I should write this post. It obviously makes a potentially controversial statement. A fellow developer who knew I was drafting it put my hesitance into perspective: "you really want to be that guy?" This was my response:
I want to be the guy who saves people pain. But sometimes to do that, you have to tell your friend if she wants to stop being punched in the face, she needs to leave the guy who keeps punching her in the face.
This post is ju [read] Keywords: agent
domino
formula language
ibm
lotus
lotusscript
notes
xpages applications
development
java
javascript
openntf
wiki
125
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
domino
xpages application
development
properties
security
136
org.openntf.xsp.extlib
Mon, Jan 21st 2013 5:20a Tim Tripcony About 18 months ago, I created an OpenNTF project called Community Control Library. The fundamental reason for creating the project was my belief that the single factor keeping the Domino community from realizing the true potential of the platform is the assumption that the XPages Extension Library is the extension library, not an extension library. Let's briefly revisit its history:
IBM starts an internal project, code named "Porus" (in reference to the Greek / Roman god of plenty), inte [read] Keywords: domino
ibm
notes
policies
xpages application
applications
best practice
community
development
openntf
wiki
