myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Shabalov <>
Subject Re: IDEA: client-side state manager that restores majority of saved state from initial tree state
Date Fri, 22 Dec 2006 04:48:36 GMT
Seems like the subject nether become obsolete nor irrelevant from the 
beginning of 2006. I mean it is still important for may (including 
myself) and not yet resolved. IMHO the "statefull" nature of JSF is most 
obvious problem of this technology.

I wonder if we can come up with some solution within latest spec or we 
must postpone this till rise of JSF 2.0?


Jacob Hookom wrote:
> Adam Winer (Oracle ADF), Ed Burns (JSF Co-Spec Lead), and myself 
> talked about this in combination with Facelets at JavaOne last year, 
> we actually have some numbers generated:
> (video, excuse my Minnesota slang)
> Facelets currently does have an option to build a tree completely on 
> post back as an alternative to StateSaving, some of this (theory) is 
> described here:
> Some caveats occur with UIInputs default behavior for 
> ValueChangeListeners instead of comparing the sent value to the bound 
> variable, it instead compares to the last value rendered-- preventing 
> a stateless postback from firing ValueChangeEvents.  There are 
> others-- but the moral is that any state stored should be an extreme 
> rarity if we can assert a consistent component model (everything is a 
> UIComponent). JSF's unique approach to View/Model separation only 
> re-enforces the perspective of UIComponents as pure mediators for the 
> request (render or postback).  JSF's rules around Client Id generation 
> and API methods such as findComponent and invokeOnComponent prove that 
> we can do some pretty cool things with structual consistency.  I would 
> like to see this re-architected for JSF 2.0 such that only sparse 
> usages of a @Stateful annotation on a UIComponent's member field is 
> required and viewstate can then stay below a few hundred bytes instead 
> of a few hundred kilobytes, stateless in most cases unless you have 
> some 'counter' component.
> With frameworks such as JMaki, Dojo, YUI-Ext, etc-- we are seeing a 
> strong push to componentize within the browser via JavaScript-- well, 
> as we talked about in our JavaOne presentation-- there's usually some 
> server-side facet to mediate the communication.  Many of these 
> frameworks require development of separate endpoints, but if we take 
> something like JSF's specific rules for page/clientId negotiation-- 
> then we can start to combine/relate these components in a richer 
> fashion on the server.  Many solutions such as JMake, Dojo, and GWT 
> try to mediate multiple events on the client, resulting in 5 or 6 
> separate request/responses to complete a task on the client (even 
> initial load)-- where the Avatar/Ajax4jsf solutions can deliver 
> multiple changes from their UIComponent counterparts in a single 
> request/response, while keeping within the full JEE stack on the server--
> -- Jacob
> Thomas Spiegl wrote:
>> 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 <> 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?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message