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

[Alexander Smirnov]

On 09/28/2009 01:30 AM, Werner Punz wrote:
> On Sun, Sep 27, 2009 at 9:09 PM, Jim Driscoll<Jim.Driscoll at sun.com>  wrote:
>> Hey Alexander:
...
>>
> Actually yes we are very modular, the reasons were threefold:
> - First we wanted to keep the path to future extensions on the
> transport part as open as possible
> - Secondly, having done a load of work with dojo I simply prefer to
> have javascript modular one way or the other (dojo does it in a more
> aggressive manner than we do, because they also load the stuff
> dynamically, optionally, while we bind our modules simply in the build
> process)
> - Third, when we started this we had some corporate users who wanted
> to have Dojo as transport mechanism, although I like Dojo I preferred
> not to introduce a dependency for a core library, but I wanted to keep
> the path open for those users to replace the I/O transport layer,
>
> So far the aggressive modularization worked out pretty well for us.
>
> But given the state of the API as an external user I only would use
> the module part if I knew that I would not switch at least the
> scripts!
>
> You nail yourself down to one implementation. My personal guess is
> that the core API although it is very small (Thank god I prefer
> minimalistic approaches over API clutter) it leaves enough flexibility
> so that you can add your own extensions from the outside.
We are talking about modularity from different points of view, I guess. 
I meant server-side modularity, where only AjaxBehavior renderer knows 
about which library to load and how to interact with it. Therefore, any 
library or even application developer can replace existing transport by 
Dojo, jQuery or everything else that he wants by replacing only one 
renderer. If that code properly implemented JSF API from both sides, it 
should be transparently for all other components that believe on 
AjaxBehavior API.
>
>
> But as Jim Driscoll has stated if you provide such a thing as official
> extension points in a dynamic language, it is hard to ensure that
> two libraries do not add extensions which are incompatible to each other.
> (Which is a non issue for now for us since the modular parts are in
> impl only and not
> part of the spec or api)
>
> The only way I can see it is to either just add additional listeners or to
> clearly specify the impl submodules and their interfaces and make them
> delegatable
> just like jsf does, or add some kind of chain patters which allow to plug users
> their own implementations on top of the chain.
>
> However we still cannot prevent that anyone does something nasty with
> the runtime, this is javascript after all, but so no library can.
> So there is a way to introduce more extension points, but we have to
> be careful where and how.
>
>
>> If you're interested, we could work together on a POC for this functionality
>> that met the current spec.  We could add that into the next rev of the impl
>> - that could fix it for you well before the next spec rev.
>>
>> We could coordinate that effort on the ajax sub-list.  At a minimum, Werner,
>> Ted and Andy should also be watching what direction we head in, so we don't
>> waste too much time going down a road that they disapprove of.
>>
> I´m in if you guys want me as a watcher, I also would recommend Ganesh
> Jung or Alexander Bell for the job, we basically worked on equal parts
> on the myfaces scripts.
>
>
>> Please note that at least one person on this list (Ken) has already
>> expressed discomfort at making these changes, since the bugs they could
>> introduce would be difficult to track.  It's not clear that the
>> functionality that you're looking for will meet the approval of the EG  But
>> the sooner we start, the sooner we can start to sort through that.
>>
>>> I think it breaks flexibility provided by pluggable JSF
>>> model.
>>
>> Well, as I said, if you modify the jsf.js file, and someone else does as
>> well - how will those two interact?  They won't.  Which is why it's a bad
>> idea.  I'd argue that we should expect that frameworks will *not* supply
>> their own jsf.js - only implementations, of which there are two.
>>