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_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?
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_facelets.dev.java.net
> For additional commands, e-mail: dev-help_at_facelets.dev.java.net
>