This is another post based upon learning from the sessions I’ve been doing at LUGs this year. Partial Execution is extremely powerful, probably rarely used, but thanks to Tony McGuckin and Dan O’Connor has been made much easier to use in IBM Domino Social Edition.
But before I even discuss Partial Execution, it’s critical to have a proper understanding of what happens during a refresh. If you’ve worked with XPages for a while, you probably understand all the steps without realising it. But it’s worth a recap. But it’s so easy to implement, it’s often used without fully understanding all the nuances of what’s happening or how it can be tuned for improving the performance of your XPages.
Pre-XPages
First, let’s be clear about what happened in the world before XPages.
In traditional Notes Client applications, everything in the current frame is submitted to the server, you define what is changed on the server and all changes to the visible NotesUI objects are pushed back. There is no concept of partial refresh.
In traditional web development, by default everything in the current form is passed back to the server, you define what is changed on the server and which page the user then goes to. If you want to do anything partial, you need to use an AJAX request and specifically define what gets passed to the server, what happens on the server and what gets passed back to the browser, which youo then need to handle via (client-side) JavaScript.
The World of XPages
In XPages it’s much easier to do a partial refresh – it’s one click of a checkbox. But this oversimplifies what happens and I’m not sure all XPages developers fully understand this. In any partial refresh three aspects at play:
- Submit ID – what is passed back to the server from the browser.
- Exec ID – what happens on the server.
- Refresh ID – what is passed back to the browser from the server.
In this post I’m focussing on what’s happening between browser and server.
By default, everything gets passed from the browser to the server. You can get around that, if you want to use XSP.partialRefreshGet() specifying the $$xspsubmitvalue.
I’ll come back in my next post to Exec ID.
If you are doing a full refresh, the whole page gets passed back to the browser. Otherwise, just the area within the refresh ID. Providing the server processing is successful, all the HTML for every control that generates HTML and has a rendered property that evaluates to true is passed back, whether it’s visible or not. And this is why it’s good practice to partially refresh as much as possible, not only because it provides a better user experience. It also minimises the traffic from server back to browser. But it only minimises traffic from server back to browser. Refresh ID has no other effect and I think this is a common misunderstanding from those starting with XPages.
In my next post I’ll cover what happens on the server, which has more options and affects whether the attempted refresh is successful and, if so, the properties and values in the HTML that gets passed back to the browser.
