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

[Jim Driscoll]

More comments below:

On 9/28/09 5:08 PM, Alexander Smirnov wrote:
> There are options that we would like to have :
> 1) extended Queue. We have a smart enough implementation and wish to
> keep that in future releases. It was also designed to work together with
> Jboss Seam framework.

As you point out later in your reply, you can do this now for your own 
components (by wrapping the jsf js calls), just not anybody else's. 
That's pretty much what you have now, right?

You could also dyanamically redefine the jsf.ajax.request function, 
storing the existing function in a private variable, and then calling 
down to it. That would work, and probably not mess up other libraries. 
That doesn't require replacing the jsf.js file either - though that way 
of doing things makes me a touch nervous, it's still better than 
replacing jsf.js with custom functionality.

I think that an intercept would be the best way to handle this for 2.1. 
  I'll try to write something up in a few weeks, with the release behind 
us.  But again, as I said previously, it's not clear that others will 
agree with this as an approach - so this may not be something that folks 
want to go into the spec.

> 2) Dynamically append scripts and styles for components that were
> included into view during AJAX request, so their resources were not
> rendered with initial request.

We can dynamically add scripts now, in both MyFaces and Mojarra.  It 
needs to be added to the spec in 2.1, but it's there now.   If you want 
to dynamically add styles as well, why not file an RFE?

> 5) Remove event listeners from DOM elements that was replaced during
> AJAX requests. JavaScript does not have methods to get listeners
> attached to particular DOM element, but they can prevent DOM objects
> from destroying by JavaScript engine and cause memory leaks. There is no
> common way to cleanup removed content, but we can do that for at least
> our components and most popular libraries.

If there's a bug in the implementation, the way to fix it isn't to 
replace the implementation - rather, the way to properly fix it is to 
fix the implementation.  Please file bugs against Mojarra for bugs in 
our implementation - I do promise to fix them.  I've filed bug #1342 for 
this issue.

> I wish to proper divide responsibility between EG and implementations or
> custom components developers. Specification should provide well-defined
> API but does not enforce to use particular implementation.

There's good reasons why this isn't true on the client side, as much as 
it is on the server side.

Maybe the best way to see if we're on the same page is to see if we both 
agree with the following statement:

"It should always be possible for ajax components from two different 
libraries to be used on the same page"

I agree fully with this statement.  Do you?  If not, that's the source 
of our disagreement.

Jim