Dennis Byrne wrote:
I guess I look at this stuff much differently with JSF. Watching Ted
Neward's interview on SOA
(http://www.theserverside.com/news/thread.tss?thread_id=39757), it got
me thinking that these AJAX solutions are doomed to pursue the same route.
[OT]
I have only listened to the first 15 minutes. Neward is a smart guy but I don't buy the "Spouse" example. Although a spouse href can point to a cat, he does not mention that modelling that relationship in Java has it's limitations as well. For example, there is no way to guarantee this in any language:
dennis.getSpouse() == tatiana & tatiana.getSpouse() == dennis
(which is true in XML also). A better way to model that situation would be to
just create a marriage class.
It doesn't resolve the fact that transporting contextual data like that
is much more expensive than the result of the evaluation for the UI.
Yes, this doesn't apply for more 'interesting' components, but most of
the time developers just want to update parts of the screen. Why go
through a series of intermediary expectations back on the developer as a
special case when it can be done so easily by just asking the component
to re-render itself?
I do get what you mean by "selling" JSF and waiting for a round trip to
the server for a full refresh. What if you were able to simply request
a single component from the server to be re-rendered via AJAX? No
waiting for a full refresh of the screen, no need to develop specialized
intermediaries/RPC wrappers, just refresh this area or re-render the
h:message for some component based on the state of your input.
(ADF/Exadel/Avatar)
So there's a simple foundation that can be leveraged for the 80% case of
updating parts without extra development or wasteful data marshalling
over the network. The 20% case, which is to optimize specific types of
component interaction w/ pre-fetching or JavaScript handwaving at the
data layer, then continue with specialized PhaseListeners, Filters, and
Servlets.
