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

[Alexander Smirnov]

On 09/29/2009 04:00 PM, Jim Driscoll wrote:
> 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.
Yes, that is exactly way that our developers go.
>
> 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?
Oops, I missed that feature, even thought I try to pay close attention 
to Mojarra code. Can you tell me function name / line number where it is 
implemented ? Stylesheets have a same importance for many components, so 
both of them should be processed in a same way.
>
>> 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 do not think what that is possible to do in common way, because it 
requires to provide patched versions of libraries that know how to 
register listener to let library to remove it from deleted elements...
>
>> 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.
I do not see a big difference between these sides. Both JavaScript and 
Java have a similar flexibility, although JavaScript has no way to be 
type safe. That is why I prefer to define Java API only, similar to 
behaviors, that encapsulates functionality for both sides, and let its 
implementation to generate particular client-side code.
>
> 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.
Yes, of course I agree with that.
>
> Jim