Jurgen Lust schrieb: > Hi Simon, > > I've setup a little test application here: > > https://ninja.ugent.be/orchestra-test/ > > You should open this url in 2 different windows, so you have different > conversationContexts. Then just follow the instructions on the page. > You will see the a4j:commandButton updates the conversation scoped > property, while the rich:datascroller updates the datatable in both > conversations. >
Hmm. I've given it a try and that sure is odd behaviour. I've used the firefox "live http headers" plugin, and it does seem that the requests are sending the right urls. With two windows: * in window 1, the button and table-scroller both send "?conversationContext=2" * in window 2, the button and table-scroller both send "?conversationContext=3" However as you say, the simple counter appears to work as expected (separate count in each window) while the table-scroller page-number is coupled between windows (next-page in one window, then next-page in the other moves forward two pages). I wonder: is the "current page in table" held in a backing bean at all, or is it held by the component itself? I don't know much about richfaces, but in tomahawk I believe the datascroller's "current index" is a property of the JSF component itself, not a property on a backing bean. If each RichFaces ajax postback is reusing the same component tree (ie restoring the same view components) then that would explain things; after render of window1 the "current page" is being saved in the component's saved-state and then on postback from window2 the "current page" is being restored from that same data. I can't remember for the moment what JSF does when two GET requests for the same viewId are processed; does it create a new UIViewRoot on the second request, or restore the first one? In the case of client-side-state, a new view obviously *must* be created as there is no posted state info. In the case of server-side-state I would have expected the same behaviour for consistency. Looking at your page, I see hidden input fields with name "javax.faces.ViewState", indicating that you have client-side-state enabled. But these hidden fields are nested within <fieldset> tags, not at the end of the <form> tag as I would normally expect with MyFaces. Is this something that RichFaces changes in order to be able to do partial-submits easier? In this case, maybe the RichFaces change to the way state-saving is done means that the same component tree is getting restored for posts by both windows.. I don't like to point the finger at someone else, but at the moment I cannot think of any way that Orchestra could be getting this wrong; the conversationContext params are right, and that is just an index into a map of conversations. The only possibility is that somehow the same backing bean has been stored into both conversationContexts but it is not likely. The above suggestion re a shared component instance seems more probable than a shared backing bean. Maybe you should ask on the RichFaces list about this.. Regards, Simon
