You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Thomas Andraschko <zo...@googlemail.com> on 2012/05/09 10:52:47 UTC
Switch state saving method per page
Hi,
is it possible to switch client/server state saving per page like in
Trinidad?
I would create an ViewMetaData annotation with CODI and own StateManager
which overwrites isSavingStateInClient and reads this MetaData via
ViewConfigDescriptor and return true/false.
Is this possible or are the more changes/code required?
Thanks!
Thomas
Re: Switch state saving method per page
Posted by Thomas Andraschko <zo...@googlemail.com>.
Hi Leonardo
thanks for your description - now i understand the state classes much
better!
Also, as far as i understand now, overwriting isSavingStateInClient()
should be enough.
I already implemented a StateManagerWrapper and it works (as far as i see).
My fail was that i extracted the viewId from the viewRoot which is (of
course) null before the view was restored.
Now i also wrap the restoreView() method and store the current viewId in
the facesContext attributes and use this if viewRoot == null.
Do i miss something or are these changes enough?
Thanks!
Thomas
2012/5/10 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> In theory there are two modes: client side and server side, but in
> theory it is also possible to create modes that combines both
> strategies or new ones. For example, just use client side for some
> small views and use server side for other ones, or force in some use
> cases to use server side state saving.
>
> In the spec there are these classes:
>
> javax.faces.application.StateManager : Encapsulate everything related
> to state saving, including apply the state to the component tree or
> calculate the state from the tree. Also, it delegates to the
> ResponseStateManager the task of store the information necessary to
> restore the state into the page (javax.faces.ViewState html hidden
> field).
>
> javax.faces.view.StateManagementStrategy : This is the one responsible
> to colaborate with the VDL and get the state. This includes details
> about Partial State Saving algorithm and it is unique per VDL.
>
> javax.faces.render.ResponseStateManager : This is the one responsible
> to colaborate with the Renderkit implementation to write the state,
> encrypt, and decode the state. It deals also with store the state and
> later restore the state.
>
> The problem here is the ResponseStateManager in my opinion has too
> many responsibilities, so override it means reimplement many stuff
> that the implementation should do. StateCache aims to do that,
> providing a clean interface with few methods that encapsulates the
> operations of store / retrieve the state.
>
> With the current spec you should implement a wrapper for each
> RenderKit and override all ResponseStateManager instances (usually
> only one HTML_BASIC renderkit), so in this case JSF shows how
> extensible is. But to do what you want is necessary to copy some code
> from MyFaces internals and that is not the idea.
>
> The problem is according to the method used (client side or server
> side) there are some small details that makes too difficult to create
> a clean API, so in that sense the spec looks good.
>
> regards,
>
> Leonardo Uribe
>
> 2012/5/9 Thomas Andraschko <zo...@googlemail.com>:
> > Hi Leonardo,
> >
> > i already checked this classes and server/client StateCache will be
> > switched via isSavingStateInClient().
> > So why it is required to make it more pluggable? Sorry but it's really
> hard
> > to understand who and where the state will be written or restored because
> > there are many classes for the state saving stuff :/
> >
> > Thanks,
> > Thomas
> >
> >
> > 2012/5/9 Leonardo Uribe <lu...@gmail.com>
> >
> >> Hi Thomas
> >>
> >> I think to make it work correctly it is necessary to do some stuff
> >> inside MyFaces internals. Look these classes:
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/StateCache.java
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ServerSideStateCacheImpl.java
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ClientSideStateCacheImpl.java
> >>
> >> The intention is make something more pluggable here, so the idea is
> >> allow override the state saving caching strategy, hiding some other
> >> details. It is a work in progress, but if you have some ideas help is
> >> welcome, we can try it and include it directly into myfaces core.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2012/5/9 Thomas Andraschko <zo...@googlemail.com>:
> >> > I tried it but somehow it does not work and i get an new or empty
> >> ViewState
> >> > field on postbacks.
> >> > Would be cool if anyone could guide me before i must read and
> understand
> >> > the complete state saving code :-)
> >> >
> >> > 2012/5/9 Thomas Andraschko <zo...@googlemail.com>
> >> >
> >> >> Hi,
> >> >>
> >> >> is it possible to switch client/server state saving per page like in
> >> >> Trinidad?
> >> >> I would create an ViewMetaData annotation with CODI and own
> StateManager
> >> >> which overwrites isSavingStateInClient and reads this MetaData via
> >> >> ViewConfigDescriptor and return true/false.
> >> >> Is this possible or are the more changes/code required?
> >> >>
> >> >> Thanks!
> >> >> Thomas
> >> >>
> >>
>
Re: Switch state saving method per page
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
In theory there are two modes: client side and server side, but in
theory it is also possible to create modes that combines both
strategies or new ones. For example, just use client side for some
small views and use server side for other ones, or force in some use
cases to use server side state saving.
In the spec there are these classes:
javax.faces.application.StateManager : Encapsulate everything related
to state saving, including apply the state to the component tree or
calculate the state from the tree. Also, it delegates to the
ResponseStateManager the task of store the information necessary to
restore the state into the page (javax.faces.ViewState html hidden
field).
javax.faces.view.StateManagementStrategy : This is the one responsible
to colaborate with the VDL and get the state. This includes details
about Partial State Saving algorithm and it is unique per VDL.
javax.faces.render.ResponseStateManager : This is the one responsible
to colaborate with the Renderkit implementation to write the state,
encrypt, and decode the state. It deals also with store the state and
later restore the state.
The problem here is the ResponseStateManager in my opinion has too
many responsibilities, so override it means reimplement many stuff
that the implementation should do. StateCache aims to do that,
providing a clean interface with few methods that encapsulates the
operations of store / retrieve the state.
With the current spec you should implement a wrapper for each
RenderKit and override all ResponseStateManager instances (usually
only one HTML_BASIC renderkit), so in this case JSF shows how
extensible is. But to do what you want is necessary to copy some code
from MyFaces internals and that is not the idea.
The problem is according to the method used (client side or server
side) there are some small details that makes too difficult to create
a clean API, so in that sense the spec looks good.
regards,
Leonardo Uribe
2012/5/9 Thomas Andraschko <zo...@googlemail.com>:
> Hi Leonardo,
>
> i already checked this classes and server/client StateCache will be
> switched via isSavingStateInClient().
> So why it is required to make it more pluggable? Sorry but it's really hard
> to understand who and where the state will be written or restored because
> there are many classes for the state saving stuff :/
>
> Thanks,
> Thomas
>
>
> 2012/5/9 Leonardo Uribe <lu...@gmail.com>
>
>> Hi Thomas
>>
>> I think to make it work correctly it is necessary to do some stuff
>> inside MyFaces internals. Look these classes:
>>
>>
>> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/StateCache.java
>>
>>
>> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ServerSideStateCacheImpl.java
>>
>>
>> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ClientSideStateCacheImpl.java
>>
>> The intention is make something more pluggable here, so the idea is
>> allow override the state saving caching strategy, hiding some other
>> details. It is a work in progress, but if you have some ideas help is
>> welcome, we can try it and include it directly into myfaces core.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2012/5/9 Thomas Andraschko <zo...@googlemail.com>:
>> > I tried it but somehow it does not work and i get an new or empty
>> ViewState
>> > field on postbacks.
>> > Would be cool if anyone could guide me before i must read and understand
>> > the complete state saving code :-)
>> >
>> > 2012/5/9 Thomas Andraschko <zo...@googlemail.com>
>> >
>> >> Hi,
>> >>
>> >> is it possible to switch client/server state saving per page like in
>> >> Trinidad?
>> >> I would create an ViewMetaData annotation with CODI and own StateManager
>> >> which overwrites isSavingStateInClient and reads this MetaData via
>> >> ViewConfigDescriptor and return true/false.
>> >> Is this possible or are the more changes/code required?
>> >>
>> >> Thanks!
>> >> Thomas
>> >>
>>
Re: Switch state saving method per page
Posted by Thomas Andraschko <zo...@googlemail.com>.
Hi Leonardo,
i already checked this classes and server/client StateCache will be
switched via isSavingStateInClient().
So why it is required to make it more pluggable? Sorry but it's really hard
to understand who and where the state will be written or restored because
there are many classes for the state saving stuff :/
Thanks,
Thomas
2012/5/9 Leonardo Uribe <lu...@gmail.com>
> Hi Thomas
>
> I think to make it work correctly it is necessary to do some stuff
> inside MyFaces internals. Look these classes:
>
>
> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/StateCache.java
>
>
> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ServerSideStateCacheImpl.java
>
>
> http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ClientSideStateCacheImpl.java
>
> The intention is make something more pluggable here, so the idea is
> allow override the state saving caching strategy, hiding some other
> details. It is a work in progress, but if you have some ideas help is
> welcome, we can try it and include it directly into myfaces core.
>
> regards,
>
> Leonardo Uribe
>
> 2012/5/9 Thomas Andraschko <zo...@googlemail.com>:
> > I tried it but somehow it does not work and i get an new or empty
> ViewState
> > field on postbacks.
> > Would be cool if anyone could guide me before i must read and understand
> > the complete state saving code :-)
> >
> > 2012/5/9 Thomas Andraschko <zo...@googlemail.com>
> >
> >> Hi,
> >>
> >> is it possible to switch client/server state saving per page like in
> >> Trinidad?
> >> I would create an ViewMetaData annotation with CODI and own StateManager
> >> which overwrites isSavingStateInClient and reads this MetaData via
> >> ViewConfigDescriptor and return true/false.
> >> Is this possible or are the more changes/code required?
> >>
> >> Thanks!
> >> Thomas
> >>
>
Re: Switch state saving method per page
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Thomas
I think to make it work correctly it is necessary to do some stuff
inside MyFaces internals. Look these classes:
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/StateCache.java
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ServerSideStateCacheImpl.java
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/renderkit/ClientSideStateCacheImpl.java
The intention is make something more pluggable here, so the idea is
allow override the state saving caching strategy, hiding some other
details. It is a work in progress, but if you have some ideas help is
welcome, we can try it and include it directly into myfaces core.
regards,
Leonardo Uribe
2012/5/9 Thomas Andraschko <zo...@googlemail.com>:
> I tried it but somehow it does not work and i get an new or empty ViewState
> field on postbacks.
> Would be cool if anyone could guide me before i must read and understand
> the complete state saving code :-)
>
> 2012/5/9 Thomas Andraschko <zo...@googlemail.com>
>
>> Hi,
>>
>> is it possible to switch client/server state saving per page like in
>> Trinidad?
>> I would create an ViewMetaData annotation with CODI and own StateManager
>> which overwrites isSavingStateInClient and reads this MetaData via
>> ViewConfigDescriptor and return true/false.
>> Is this possible or are the more changes/code required?
>>
>> Thanks!
>> Thomas
>>
Re: Switch state saving method per page
Posted by Thomas Andraschko <zo...@googlemail.com>.
I tried it but somehow it does not work and i get an new or empty ViewState
field on postbacks.
Would be cool if anyone could guide me before i must read and understand
the complete state saving code :-)
2012/5/9 Thomas Andraschko <zo...@googlemail.com>
> Hi,
>
> is it possible to switch client/server state saving per page like in
> Trinidad?
> I would create an ViewMetaData annotation with CODI and own StateManager
> which overwrites isSavingStateInClient and reads this MetaData via
> ViewConfigDescriptor and return true/false.
> Is this possible or are the more changes/code required?
>
> Thanks!
> Thomas
>