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

[Ted Goddard]

For ICEfaces we are using the jsf.js library as-is for the core
Ajax functionality.  Replacing it is sure to cause interoperability
problems.

Ted.

On 2009-09-25, at 1:26 PM, Alexander Smirnov wrote:

> 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
>>>