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

[Jim Driscoll]

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