dev@javaserverfaces.java.net

Re: IDEA: client-side state manager that restores majority of saved state from initial tree state

From: Jacob Hookom <jacob_at_hookom.net>
Date: Wed, 20 Dec 2006 23:32:11 -0600

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:

http://weblogs.java.net/blog/edburns/archive/2006/05/javaone_video_a_1.html
(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:

http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html

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 <mkienenb_at_gmail.com> 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?
>>
>
>