Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44327840.8030604@hookom.net>
Date: Tue, 04 Apr 2006 08:44:32 -0500
From: Jacob Hookom <jacob@hookom.net>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: MyFaces Development <dev@myfaces.apache.org>
Subject: Re: What's a POJSO ?
References: <W355992801948911144135705@webmail24>
In-Reply-To: <W355992801948911144135705@webmail24>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.