[EMAIL PROTECTED] schrieb: > 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.. >
Hmm..actually, what happens if you just make the backing bean request-scoped? Can you still scroll through pages with the data scroller? And if so, what happens with two windows? Regards, Simon
