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

[Ganesh]

Hi,

I'm actually using Mojarra 2.0 together with MyFaces' Javascript which
prooves that the client side library can be easily replaced. It just takes
1 line of code to wrap that mojarra.ab() function around jsf.ajax.request.
Then put your replacement script on the web doc path of your app (that has
precedence before the classpath according to the spec) and you're gone.

This is the example app I'm running with this config:
http://www.j4fry.org/JSFExamples20/page/dojo.faces

Best regards,
Ganesh

Jim Driscoll schrieb:
> Hey Alexander:
> 
> On 9/25/09 12: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.
> 
> I'm not sure what you're referring to here: Do you mean the mojarra 
> namespaced functions?  Those should be completely separate - that's why 
> they're in a different namespace.  Putting them into a separate file has 
> performance implications.  And if you think Mojarra's jsf.js file has 
> other functions, check out MyFaces - they're much more agressive in 
> breaking out functionality - an architecture that Mojarra will probably 
> follow in the next rev as well.
> 
>> Therefore, it is not possible to easy replace
>> client side library for AJAX functionality only,
> 
> That was never the intention of either the spec or the implementation, 
> AFAIK.  The reason why is easy enough - if every framework wants to do 
> that, then only one framework can - and that would be very bad, since 
> you could never then mix those frameworks in a page.
> 
>> and we have not enough
>> extension points in the standard API to provide additional
>> functionality.
> 
> What extension points are you looking for?  Please be specific, since 
> this will be what we discuss in the next rev of the spec.
> 
> One thing I've been contemplating (primarily to accomadate RichFaces 
> functionality) was to change the event system from a monitor function to 
> an intercept function - allowing the cancelation or delay of queued 
> request from the begin event, for instance (for queues and aggregation) 
> or allowing modification of the submitted render and execute fields (for 
> things like autoupdate).
> 
> 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.
> 
> 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.
> 
> Jim
>