[jsr-314-open] AJAX library in JSF 2.0
Jim Driscoll
Jim.Driscoll at Sun.COM
Tue Sep 29 19:00:01 EDT 2009
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
More information about the jsr-314-open-mirror
mailing list