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 <[EMAIL PROTECTED]> 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 <[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?
> >>>
> >>
> >>
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
