myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject Re: Switch state saving method per page
Date Thu, 10 May 2012 15:48:12 GMT

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

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.


Leonardo Uribe

2012/5/9 Thomas Andraschko <>:
> 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 <>
>> Hi Thomas
>> I think to make it work correctly it is necessary to do some stuff
>> inside MyFaces internals. Look these classes:
>> 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 <>:
>> > 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 <>
>> >
>> >> 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
>> >>

View raw message