Re: [jsr-314-open] AJAX library in JSF 2.0

Our team just caught the problem with Mojarra implementation. Although interaction with client-side code is encapsulated into AjaxBehavior renderer, jsf.js library contains code that used by the some other renderers from Jsf-impl. Therefore, it is not possible to easy replace client side library for AJAX functionality only, and we have not enough extension points in the standard API to provide additional functionality. I think it breaks flexibility provided by pluggable JSF model. On 09/14/2009 05:17 PM, Alaxander Smirnov wrote: > I think Dan paint too dark picture about "dump in the kitchen sink" > JSF > 2.0 AJAX implementation library. I always kept in mind during AJAX > API > development to make it flexible and extensible to give us and other > independent vendors place for innovations. From my point of view, the > most important thing to use the same Java and JavaScript API for all > component libraries to keep them interoperable. > But, it also seems for me that using only one implementation ( or > two ? > ) is not very productive. Different component vendors could have a > different release plans, different extensions and requirements. Also, > because core JSF libraries supposed to be integrated into > container, in > many cases it would be much hard to application developers to change > implementation version instead of component library. Also, Mojarra > ( and > MyFaces ) teams have limited resources, that cam slow down > propagation > of features to implementation. So, the best strategy for JSF AJAX > development would be extensions from different vendors that could be > fine tested by their developers and community. JSF implementation > library should adopt the best solutions as it already done for JSF > 2.0 > AJAX API. > Of course, any extensions should be compatible with public API, and > any > components should relay for that API only, so it is up to application > developer that implementation to use. > > On 09/14/2009 07:48 AM, Roger Kitain wrote: >> Hey Pete - >> >> Thanks for the clarification - that's what I thought based on prior >> discussions I've >> had with Alex. Yes, ICEFaces had done some preliminary work with >> JSF 2.0: >> http://www.java.net/blog/2009/05/25/icefaces-20-and-jsf-20-together >> And I'm sure ADF Faces will follow suite (if they haven't started >> already). >> >> -roger >> >> Pete Muir wrote: >>> >>> On 13 Sep 2009, at 22:53, Jim Driscoll wrote: >>> >>>>> I hope that AJAX4JSF is modified so that it builds on top of >>>>> the JSF >>>>> standardized APIs instead of being a complete replacement for >>>>> them. >>>> >>>> That's something that can best to achieved by their customers >>>> lobbying the AJAX4JSF people. >>>> >>>> AFAIK, there's nothing to stop them specifically from adopting the >>>> current API set - other than their reluctance to rewrite an >>>> existing >>>> codebase. But that's based on the one link that you sent on - >>>> you'd >>>> have to ask them directly if that's true. >>> >>> Essentially this is the opposite of the RichFaces 4 plan (I agree, >>> the comment that this discussion is based on is ambiguous at best). >>> Just like ICEFaces, we intend to build RichFaces 4.0 on top of the >>> JSF 2 Ajax API. I've asked Jay (RichFaces project lead) to blog in >>> detail on this to clear up the confusion :-) >>> >>> From initial discussions with Alex, my understanding is JSF 2 Ajax >>> will account for around 70% of what was in Ajax4JSF (which IMO just >>> validates how complete JSF 2 Ajax is!). The remaining 20% has not >>> been specified (not ready yet, or no consensus or ...), and will be >>> built as extensions on top of JSF 2 Ajax. >>> >>> HTH >>