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 <zoi...@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 <lu4...@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 <zoi...@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 <zoi...@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 >> >> >>
