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]
