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

[Alexander Smirnov]

I probably rushed to send initial message based on our team concerns 
only, without deep investigation of the implementation details. I spent 
this Monday to put all things together into order.

On 09/27/2009 12:09 PM, Jim Driscoll wrote:
> 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.
I guess what it was unclean in my point. For me, ClientBehavior would 
encapsulate all JavaScript rendering/decoding functionality, so it 
doesn't matter which JavaScript code was really generated. Custom 
renderer would provide its own library for particular client type ( for 
example, with iPhone or mobile render kit. It is also actual for portal 
environment where all JavaScript function names should be namespaced to 
prevent inter-portlet conflicts. ), or introduce its own extensions. Any 
component library would believe on Java ClientBehavior/AjaxBehavior API 
only, so it does not matter which implementation is really used by 
application. Of course, particular AJAX library should provide 
client-side API functions for application developers who needs to write 
its own client-side code.
Really, jsf.js library is used by some other renderers ( in the Mojarra, 
it is commandButton / commandLink renderers ) and can't be changed with 
particular RenderKit or AjaxBehavior renderer. Of course, any extension 
can load standard jsf.js library and wrap or redefine particular API 
calls, but what about cases where that library should be replaced ?
I understand effort to put all JavaScript code into one library, that 
reduces number of requests, but, from the other hand, any JSF 
application has to load whole library even though it not use AJAX 
functionality at all. Even single commandLink component will include 
about 100kb of javascript ...
>
>> 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.
AFAIK, JSF spec has well-defined API but should not enforce particular 
implementation. We can replace at most any object by custom 
implementation that follows requirements, why client-side library should 
be exception ?
>
>> 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.
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.
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.
3) Connect 'status' component to library so in can display request 
status for all or only selected components.
4) Log AJAX execution. At the development stage, application developer 
can use special 'debug' component to analyse requests and updates.
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.

Of course, we can load standard jsf.js library and wrap/replace its 
methods or register special listeners to provide necessary 
functionality, but it does not solve special cases ( mobile or portal 
applications ).
N.B. about Mojarra implementation. It replaces the name of "jsf.js" 
library in the UIViewRoot#ComponentResources collection by 
"jsf-compressed.js" or "jsf-uncompressed.js" that depends of the project 
stage, but never specification nor API docs have any mention about that, 
so component developer can miss already loaded library.
>
> 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 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.
>
>> 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