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