Maybe you can take a look at the Trinidad approach. I think Trinidad solves state-saving more effective than tomahawk or myfaces does.
On 12/20/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
I'm a fan of client-side state saving. It solves a lot of issues for me. However, there's no doubt that it requires more bandwidth due to saving the entire component tree state in a hidden input field. I wonder how much of this is really necessary. I'm guessing 90% of the state saved is simply constant for a given page. The two examples I can think of where this wouldn't be true would be the localValue for a UIInput or java code that directly manipulates a component. It seems like the state manager could preserve (or recreate) the original state of the component from the page code, compare that state with the current state of the component, and then mark it with a boolean value (didStateChange). For most components, this would result in a save state size of one boolean (no more than a char, and could probably even been put into a bit array if one needed to. For components whose state did differ from the original state, it would require one additional boolean value. This should work for any JSF implementation. A clever implementation could go a step further and separate the state saved into "state that rarely differs" and "state that always differs (UIInput localValue, for instance)" so as to reduce even the 10% remaining. So we'd be trading off network (and html size) bandwidth for server-side processing (or perhaps memory if you were willing to cache original page states in the application). Anyone else have any thoughts on this idea?
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
