Re: orchestra and richfaces table scroller

[Jurgen Lust <ju...@gmail.com>]

Hi Simon,

You are right: the current page is stored in the component state. When
I put the backing bean in request scope, I get exactly the same
behaviour.

I don't use client side state saving by the way, the
javax.faces.ViewState fields are added by RichFaces I guess.

Now I am wondering, would it theoretically be possible for Orchestra
to also intervene in the server side state saving so that the
component tree is stored in a conversation context? The use of
different windows is something web users have gotten used to,
especially since tabs were introduced, and the fact that JSF does not
allow it is one of its main drawbacks I think.

Anyway, Orchestra is already a major step forward in this area. I was
planning on using Spring WebFlow to solve the conversation scope
problem, but that seemed a bit too heavyweight. Orchestra is
wonderfully light and easy to install!

Jurgen

2008/3/31, simon.kitching@chello.at <si...@chello.at>:
> simon.kitching@chello.at 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
>
>

Re: orchestra and richfaces table scroller

[Mario Ivankovits <ma...@ops.co.at>]

Hi
>> Now I am wondering, would it theoretically be possible for Orchestra
>> to also intervene in the server side state saving so that the
>> component tree is stored in a conversation context?
>>     
> Theoretically yes. And this is also a wish others expressed already.
> We will investigate if it is possible to store the server-side state in
> the conversation context, but state-saving is not one of the "gloriest"
> in JSF.
>   
By copying the MyFaces StateManager and replacing its session access by
conversationContext access it should easily possible to fix that problem.
We can look at it in the next few days .... or contribute :-)

Ciao,
Mario

Re: orchestra and richfaces table scroller

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> Now I am wondering, would it theoretically be possible for Orchestra
> to also intervene in the server side state saving so that the
> component tree is stored in a conversation context?
Theoretically yes. And this is also a wish others expressed already.
We will investigate if it is possible to store the server-side state in
the conversation context, but state-saving is not one of the "gloriest"
in JSF.

Ciao,
Mario