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

[Alexander Smirnov]

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