You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2007/10/26 11:05:18 UTC
[research] state writing with server side state saving
Hi!
Even in Facelets I have seen that it start buffering the output of the
page when it comes to state saving.
But with Server-Side-State-Saving (SSSS) it should be possible to just
render a unique id whith which the state is associated then, no?
No need to buffer anymore then.
I think with a special ViewHandler (intercept writeState to write the id
and build the state after renderView then) and a custom StateManager it
should be possible then.
Ideas?
Ciao,
Mario
Re: [research] state writing with server side state saving
Posted by Martin Marinschek <ma...@gmail.com>.
My current client would kiss you for a solution for this ;)
regards,
Martin
On 10/26/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> Even in Facelets I have seen that it start buffering the output of the
> page when it comes to state saving.
>
> But with Server-Side-State-Saving (SSSS) it should be possible to just
> render a unique id whith which the state is associated then, no?
> No need to buffer anymore then.
> I think with a special ViewHandler (intercept writeState to write the id
> and build the state after renderView then) and a custom StateManager it
> should be possible then.
>
> Ideas?
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [research] state writing with server side state saving
Posted by Michael Kurz <mi...@gmx.at>.
Martin Marinschek schrieb:
> it's a bit more: it stores the current view id and the sequence-id
> (for back-button support).
Isn't the sequence number written out separately in HtmlFormRendererBase
with SSSS (in 1.2.1)?
regards,
Michael
Re: [research] state writing with server side state saving
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Michael,
it's a bit more: it stores the current view id and the sequence-id
(for back-button support).
regards,
Martin
On 10/26/07, Michael Kurz <mi...@gmx.at> wrote:
> Mario Ivankovits schrieb:
> > But with Server-Side-State-Saving (SSSS) it should be possible to just
> > render a unique id whith which the state is associated then, no?
> > No need to buffer anymore then.
> > I think with a special ViewHandler (intercept writeState to write the id
> > and build the state after renderView then) and a custom StateManager it
> > should be possible then.
> >
> > Ideas?
>
> Just a thought, but with SSSS wouldn't it be possible to simply write a
> view state tag with constant value and skip further state writing? For
> what I have seen so far it is only used to determine if the request is a
> postback with SSSS (at least in 1.2.1, 1.1 seems to be a bit different).
> But I may be wrong...
>
> regards,
> Michael
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [research] state writing with server side state saving
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> I'm talking about both cases.
>
Ah, ok , I see.
>>> Is it necessary to support this kind of thing by backing beans in *rendering* phase? (obviously, it is quite reasonable in invokeApplication etc). I think not. In this case, state writing would become a whole lot simpler.
>>>
>>>
>> It is possible so I think it needs to be supported, though, i slowly
>> move to the side which states that this should not be the common style.
>>
>
> In what situation *does* this need to be supported?
>
> Shouldn't a facelets dynamic-include tag instead modify the tree during
> the buildView, rather than the encodeAll? That then solves the problem;
> the tree then is not modified during encodeAll so state can be computed
> at the start.
>
> The orchestra dynaForm should do the same, I think
dynaForm is already modified to modify the tree during build tree. I
think it might be possible to change the dynamic-include too.
Still we should support the "modify-tree-on-render-response" use case,
but we might be able to make this configureable. something like
org.apache.myfaces.SAVE_STATE_BEFORE_ENCODE=true|false where for
backward compatibility we use "false" as default. Yep ... should
definitely be possible. Cool then ... :-)
Ciao,
Mario
Re: [research] state writing with server side state saving
Posted by simon <si...@chello.at>.
On Sun, 2007-10-28 at 18:19 +0100, Mario Ivankovits wrote:
> Hi Simon,
>
> > I cannot get this patch to apply cleanly unfortunately. And it's
> > difficult to review the patch file directly as it has a lot of
> > whtespace-only changes.
> Sorry for that, I'll see if I can clean it up before committing, not
> sure about it.
>
> > There are now two phases to rendering for JSP: buildView then encodeAll.
> > As long as no component changes the tree during the encodeAll pass then
> > it seems to me that it is possible to just compute the serialized view
> > state at the start of the encodeAll phase [1] and write it out directly
> > when it is needed.
> Do you talk about client-side-state-saving?
I'm talking about both cases.
Just to clarify, I think that your proposed change is fine, but it
*might* be possible to clean up the existing code much further..making
your change redundant.
> This patch is just about server-side-state-saving and with this, during
> the encodeAll pase just an "ID" gets rendered, no state should have been
> built until then.
> The state is build after encodeAll (at least with Facelets, will work
> with JSP too but I think there is a bug I realized when there was no
> time to fix it).
> This means, even a modified tree structure will be correctly saved.
Yes, that's how it currently works. Right now, the saved state is not
computed until after encodeAll has completed. But why?
I'm wondering if this is just a leftover from the old JSF1.1 days where
the state *had* to be computed at the end of rendering because building
the component tree was a "side effect" of rendering.
And if the state can be computed before encodeAll is invoked, then the
"server side" and "client side" logic can effectively be unified. The
JspStateManager.saveState method can serialize the tree, then:
* for server-side, allocate a seq#, store the state in the session using
that key and return the seq# as a string.
* for client-side, return the state as a byte-array (which the renderkit
will base64-encode).
The writeState method then simply has to do what its name implies -
write the value returned by saveState to the response. For server-side
that will happen to be an integer, and for client-side that will happen
to be a bytearray. There will be no if-statements needed in the
JspViewHandler though..
>
> > There might be a couple of flaws in my reasoning though: can backing bean code invoked during render alter the tree state (eg insert data into the attributes map of a component).
> >
> Yep, is still possible, not sure how many people will use stuff like
> this. But we do - includeFacelets - you know :-)
>
> > Is it necessary to support this kind of thing by backing beans in *rendering* phase? (obviously, it is quite reasonable in invokeApplication etc). I think not. In this case, state writing would become a whole lot simpler.
> >
> It is possible so I think it needs to be supported, though, i slowly
> move to the side which states that this should not be the common style.
In what situation *does* this need to be supported?
Shouldn't a facelets dynamic-include tag instead modify the tree during
the buildView, rather than the encodeAll? That then solves the problem;
the tree then is not modified during encodeAll so state can be computed
at the start.
The orchestra dynaForm should do the same, I think - modify the tree
during buildView. It means that some logic needs to be driven by the
taghandler rather than the component, but that seems reasonable to me.
Taghandlers are responsible for building component trees, components are
not.
I'm struggling at the moment with getting myfaces1.2 to build, but if I
can solve that then I'll experiment with dynamic include and dynaForm in
this manner.
Cheers,
Simon
Re: [research] state writing with server side state saving
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Simon,
> I cannot get this patch to apply cleanly unfortunately. And it's
> difficult to review the patch file directly as it has a lot of
> whtespace-only changes.
Sorry for that, I'll see if I can clean it up before committing, not
sure about it.
> There are now two phases to rendering for JSP: buildView then encodeAll.
> As long as no component changes the tree during the encodeAll pass then
> it seems to me that it is possible to just compute the serialized view
> state at the start of the encodeAll phase [1] and write it out directly
> when it is needed.
Do you talk about client-side-state-saving?
This patch is just about server-side-state-saving and with this, during
the encodeAll pase just an "ID" gets rendered, no state should have been
built until then.
The state is build after encodeAll (at least with Facelets, will work
with JSP too but I think there is a bug I realized when there was no
time to fix it).
This means, even a modified tree structure will be correctly saved.
> There might be a couple of flaws in my reasoning though: can backing bean code invoked during render alter the tree state (eg insert data into the attributes map of a component).
>
Yep, is still possible, not sure how many people will use stuff like
this. But we do - includeFacelets - you know :-)
> Is it necessary to support this kind of thing by backing beans in *rendering* phase? (obviously, it is quite reasonable in invokeApplication etc). I think not. In this case, state writing would become a whole lot simpler.
>
It is possible so I think it needs to be supported, though, i slowly
move to the side which states that this should not be the common style.
Ciao,
Mario
Re: [research] state writing with server side state saving
Posted by simon <si...@chello.at>.
Hi Mario,
On Fri, 2007-10-26 at 22:49 +0200, Mario Ivankovits wrote:
> Please find a patch regarding the "SSSS without output buffering" here [1].
> This feature is not configurable in any way other than the current setup
> for server side state saving. It just saves usable informations in
> ViewState which was not used yet beside to check if the request is a
> postback.
>
> I have no PC during the next two days, but will commit this stuff (if no
> one complains) by Sunday evening or Monday.
>
> [1] https://issues.apache.org/jira/browse/MYFACES-1753
I cannot get this patch to apply cleanly unfortunately. And it's
difficult to review the patch file directly as it has a lot of
whtespace-only changes. However I've spent some time looking at the
existing code and the general principle seems sound.
However I wonder whether it is possible to just get rid of the
StateMarkerAwareWriter completely.
There are now two phases to rendering for JSP: buildView then encodeAll.
As long as no component changes the tree during the encodeAll pass then
it seems to me that it is possible to just compute the serialized view
state at the start of the encodeAll phase [1] and write it out directly
when it is needed. This doesn't mean that components cannot dynamically
alter the tree - it just means that they must do it before encodeAll is
invoked, ie in a taghandler rather than in encodeBegin/encodeEnd.
There might be a couple of flaws in my reasoning though: can backing bean code invoked during render alter the tree state (eg insert data into the attributes map of a component).
Is it necessary to support this kind of thing by backing beans in *rendering* phase? (obviously, it is quite reasonable in invokeApplication etc). I think not. In this case, state writing would become a whole lot simpler.
[1] well, creating this state could be postponed until first needed, just in case a page is rendered without any form in it.
Regards,
Simon
Re: [research] state writing with server side state saving
Posted by Martin Marinschek <ma...@gmail.com>.
This sounds very good. We need to discuss this on the weekend ;)
cul,
regards,
Martin
On 10/26/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> Please find a patch regarding the "SSSS without output buffering" here [1].
> This feature is not configurable in any way other than the current setup
> for server side state saving. It just saves usable informations in
> ViewState which was not used yet beside to check if the request is a
> postback.
>
> I have no PC during the next two days, but will commit this stuff (if no
> one complains) by Sunday evening or Monday.
>
> Ciao,
> Mario
>
>
> [1] https://issues.apache.org/jira/browse/MYFACES-1753
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [research] state writing with server side state saving
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
Please find a patch regarding the "SSSS without output buffering" here [1].
This feature is not configurable in any way other than the current setup
for server side state saving. It just saves usable informations in
ViewState which was not used yet beside to check if the request is a
postback.
I have no PC during the next two days, but will commit this stuff (if no
one complains) by Sunday evening or Monday.
Ciao,
Mario
[1] https://issues.apache.org/jira/browse/MYFACES-1753
Re: [research] state writing with server side state saving
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Just a thought, but with SSSS wouldn't it be possible to simply write
> a view state tag with constant value and skip further state writing?
> For what I have seen so far it is only used to determine if the
> request is a postback with SSSS (at least in 1.2.1, 1.1 seems to be a
> bit different). But I may be wrong...
Yep, it seems you are right.
Once we fixed the current bug regarding jsf_sequence it comes down to
exactly what you've described.
With the jsf_sequence we are able to just render a constant for the
ViewState hidden field ("ssss") and MyFaces already works correctly.
It seems there are VERY minor changes required to make this work. I've
already setup the stuff here. Just the jsf_sequence bug needs to be fixed.
Ciao,
Mario
Re: [research] state writing with server side state saving
Posted by Michael Kurz <mi...@gmx.at>.
Mario Ivankovits schrieb:
> But with Server-Side-State-Saving (SSSS) it should be possible to just
> render a unique id whith which the state is associated then, no?
> No need to buffer anymore then.
> I think with a special ViewHandler (intercept writeState to write the id
> and build the state after renderView then) and a custom StateManager it
> should be possible then.
>
> Ideas?
Just a thought, but with SSSS wouldn't it be possible to simply write a
view state tag with constant value and skip further state writing? For
what I have seen so far it is only used to determine if the request is a
postback with SSSS (at least in 1.2.1, 1.1 seems to be a bit different).
But I may be wrong...
regards,
Michael