This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal



Jun 20, 2011, 4:05 PM
47 Posts

Any way to force a refresh when changing to Edit mode to avoid replication conflicts?

  • Category: Server Side JavaScript
  • Platform: All
  • Release: 8.5.2
  • Role: Developer
  • Tags:
  • Replies: 3
 Is there any way to force a refresh of a document data source from the back end? The scenario I am dealing with seems fairly common in a collaborative application but will lead to all kinds of replication conflicts:
 
  1. User A opens a document in read mode 
  2. User B opens the same document, also in read mode.
  3. User B changes the document mode to edit, makes a change and saves the document.
  4. User A then changes the document to edit mode, makes a change and saves the document.
  5. Replication conflict!
User A has the cached copy of the document from before User B opened it. That copy should be refreshed from the back end before changing the document to edit mode to avoid these conflicts. Note that the edits themselves are not overlapping, just read access! I am changing the document edit mode with a simple action, and it was originally using partial refresh but also happens now that I have switched to using full refresh.
 
There are other situations that may modify the document at the back end after the user has opened it in read mode. This is just the simplest to reproduce. With 'document locking' of sorts I can protect the document while it is in edit mode, but I must be able to get the freshest version of the document when I switch to edit mode. 
 
Thanks for any input, 
 
RIch 
 
Jun 20, 2011, 7:41 PM
129 Posts
Re: Any way to force a refresh when changing to Edit mode to avoid replication conflicts?
I made a custom control a while back that might help you with your problem. Probably not the way you want, but at least the users are notified when another used modifies a document that he/she has open for editing.
 
I can't remember how thoroughly I tested the demoapp, so you might have to do a couple of tweaks/fixes before putting it in production. 
 
http://dontpanic82.blogspot.com/2010/01/xpages-custom-control-that-can-help.html 
Jun 22, 2011, 3:05 PM
47 Posts
Re: Any way to force a refresh when changing to Edit mode to avoid replication conflicts?
 This looks like a good idea on how to notify the users, but reloading of the whole page is what I am trying to avoid. If I could just get the xspDocument to refresh from its back end document, I could avoid notifying the user at all.
 
 
 
Jun 30, 2011, 6:12 PM
129 Posts
Re: Any way to force a refresh when changing to Edit mode to avoid replication conflicts?
I did a little testing, and this is something that seems to work.
 
Wrap the content of the XPage in a panel/set an id.
When it's detected that the document has changed, trigger a partial refresh on the wrapper panel. This could be done by executing a script in the browser that clicks a hidden button or something.
 
Execute this code on the server to "reset" the page (you have to alter the code if the document data source is connected to something other than the root node of the XPage): 
var newViewRoot = facesContext.getApplication().getViewHandler().createView( facesContext, view.getPageName() );
facesContext.setViewRoot( newViewRoot );
newViewRoot.getData().get(0).setConcurrencyMode( 'force' );
 
The above code recreates the view, and sets the document so that save conflicts won't occur if the document is saved after the view tree is rebuilt. I couldn't find another way to avoid save conflicts.    
 
If you want, you could probably trigger the server side code using the RPC module in the XPages Extension Library, or the EventDelegator technique I wrote about in my blog a while back. 
http://dontpanic82.blogspot.com/2010/12/new-and-improved-eventdelegator-with.html 
  
This isn't a complete solution, but at least you have something to test/go by :) 

This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal