Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (nike.apache.org: domain of gcjmu-myfaces-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@myfaces.apache.org
From: Werner Punz <werner.punz@gmail.com>
Subject: Re: MyFaces 2.0 development going forward
Date: Mon, 02 Mar 2009 11:17:53 +0100
Lines: 46
Message-ID: <gogboh$982$1@ger.gmane.org>
References: <254acf980902260630w5682657bh6057f8c21d277f9a@mail.gmail.com>
 <0015174bddf8d292430463d371c6@google.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
In-Reply-To: <0015174bddf8d292430463d371c6@google.com>
Sender: news <news@ger.gmane.org>

jankeesvanandel@gmail.com schrieb:
> I'm currently working on the annotation processing stuff (@ManagedBean, 
> @ManagedProperty...). Already made a first attempt for the managed 
> beans, but there is still some work to do (converters, components, event 
> listeners, etc). I hope I can apply the same logic for those other 
> components as well.
> 
> With Werner working on Ajax and Simon on Facelets, we already cover a 
> large portion of JSF2. Facelets is big, though, since it also contains 
> tags for all components, EZComp, JSF2-Facelets/Original-Facelets 
> switching, etc... Resource handling/relocation is also a mandatory 
> requirement for Ajax to work.
> 
My main problem the last few weeks was that I was assigned to another 
task which bound me for 100% I hope to have again at least one day per 
week beginning from this week to finish the client side ajax part.
We are on the client side currently at 70% :-), most of the 
roundtripping is implemented on the client side, the response handling 
still is missing! Btw. I ditched the Trinidad xhr code (I made it 
switchable so you for now still can use it).

The reason was, the Trinidad code had so many things in, which is not 
needed by the specs which made the code hard to maintain,

that a small clean room transport made more sense to keep the codebase 
leaner.

Some parts of the Trinidad xhr code still live in the new codebase, the 
form value encoding for instance. But for now there is not too much 
needed from the Trinidad codebase. I have not seen the latest spec, but 
the entire iframe aspects were not there, because no direct form submit 
was done, xhr transport only and that one queued and asynchronously 
only. By removing the trinidad codebase, I could trim the entire XHR 
codebase down by 70%, so it made sense to do it!

For now I have both transports with a small adapter layer on top of it 
to hook it into jsf2 but I am not sure if we keep the Trinidad codebase.


As for the server side, the main issue there is we have to do a 
specialized responsewriter, which pretty much Trinidad does already!
But I do not consider that too much work!


Werner