myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Hookom <ja...@hookom.net>
Subject Re: IDEA: client-side state manager that restores majority of saved state from initial tree state
Date Sun, 07 Jan 2007 21:51:58 GMT
Either that, or the eden state is assigned at first call to savestate-- 
so the initial accessor of the view would basically have an empty view 
state, since their would be treated as the benchmark for all others.  
This would allow incorporation of programmatically added components (as 
long as you always added the same components-- allowing optimization of 
savestate for redundancy of components).

Jacob Hookom wrote:
> It would be fine, just not included in the eden state-- Facelets would 
> provide the eden state, then at the time of savestate, it would be 
> compared to the passed component tree, only saving deltas.
>
> Until we get out of hierarchical state saving logic, we're going to be 
> stuck with too much state saved.  This is especially true for partial 
> requests.
>
> Martin Marinschek wrote:
>> I wonder how we can handle the case of adding components
>> programmatically with this approach.
>>
>> @Jacob: Have you thought up a solution for this?
>>
>> regards,
>>
>> Martin
>>
>> On 12/22/06, Mike Kienenberger <mkienenb@gmail.com> wrote:
>>> Yes, my "idea" was probably partially inspired by things I read over
>>> the last year so it's probably not all that original.  Glad to see I'm
>>> on the right track.
>>>
>>> It does sound like creating an alternate StateManager (which is within
>>> the JSF Spec) can accomplish this when using Facelets.   I might give
>>> this a shot at some point, although I have no timeline.
>>>
>>> On 12/21/06, Igor Shabalov <ishabalov@exadel.com> wrote:
>>> > 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?
>>> >
>>> > Best,
>>> > Igor.
>>> >
>>> >
>>> > 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:
>>> > >
>>> > > 
>>> 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@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?
>>> > >>>
>>> > >>
>>> > >>
>>> > >
>>> > > 
>>> ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@facelets.dev.java.net
>>> > > For additional commands, e-mail: dev-help@facelets.dev.java.net
>>> > >
>>> >
>>> >
>>>
>>
>>
>
>


Mime
View raw message