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

[Alexander Smirnov]

Do not afraid about my questions as a rising problems for JSF 2.0. Of 
course, all component developers would solve their problems ( and we 
will do ), but I wish to bring up my concerns, so some of them would be 
resolved in JSF 2.1 or late...

On 09/29/2009 11:28 AM, Jim Driscoll wrote:
> Some quick comments, I'll have more shortly.
>
> On 9/28/09 5:08 PM, Alexander Smirnov wrote:
>> functionality at all. Even single commandLink component will include
>> about 100kb of javascript ...
>
> We thought about that. But since it's only 16k in size compressed, (not
> 100k) latency is actually a bigger deal than throughput, even for the
> slowest of connections.
For my opinion, it would be better to let application developer/deployer 
to decide, which solution is better for particular case. In the 
RichFaces, we have up to four possible options for resources. The first 
one is fine-grained per component script and styles, that is useful for 
development stage or pages with a few components only. The second option 
is the single solid library that contains everything from whole 
component library. This library is big enough ( up to 200k of compressed 
code ), so we have a tool that builds custom application-wide libraries 
with only necessary code, and compress them by Yahoo compressor. That 
option is useful for heavy loaded production sites. Because such sites 
often use separate servers for static resources, the last option 
disables resource loading at all, so developer can put them to external 
server. According to the forum and Red Hat service requests, all these 
options are used in real applications.
>
> Of course, since it's set to never expire anyway, it's not really a big
> deal - it's only downloaded once anyhow, on first hit. So if there was a
> good reason to break it out, we could. But since we don't want folks
> replacing this library, I don't think there's a good reason to break it
> out.
Yes, this is true for a small library. Unfortunately, any code have 
habit to grow, and size of client-side code becomes a problem after a 
while :-(
>
>
>>> 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 ?
>
> Because unlike the server side, the client side can only have one
> implementation per page. This is an important difference.
JSF architecture defines the API for all its components, but let 
component library or application developer to extend or redefine at most 
everything. This approach gives us nice flexibility, but including 
implementation of the JavaScript library into API part breaks it for 
client-side. JavaScript uses late coupling to resolve names, so it is 
not important which library is loaded if it contains necessary functions 
and variables. Some of the previous messages has pointed to client who 
wants to replace AJAX transport, but I worried pretty much about 
portlets, that require all JavaScript and style class names to be 
namespaced, to avoid conflicts between different portlet instances. That 
could be done easily with EL-expressions parsing in the resources, like:
(function(jsf){
       .............
	jsf.request = function request(source, event, options) {
       .............
}(window.#{fn:encodeNamespace('jsf')} = {}));

And use EL-function to construct JavaScript name on page: 
#{fn:encodeNamespace('jsf')}(...); to properly encode JavaScript 
function names. Once again, hardcoded jsf.js library does not allow such 
processing in the portlet environment.
>
> Yes, as long as the api contract is respected fully, the implementation
> could be (theoretically) replaced - but, the whole point of replacing it
> is surely to modify the behavior in some way. Otherwise, why replace it?
> And the minute you do that, you prevent anyone *else* from replacing it
> to modify the behavior - which means that no two libraries could do
> that. And we're back to where we started, where two libraries can't be
> used in the same page. This is a Bad Thing, and we need to avoid that.
I think these points should be carefully discussed for JSF 2.1.
>
> So it's my position that libraries should not replace the jsf.js file.
> Otherwise, we'll be back to where we started, with two libraries not
> working together in the page.
I do not talk about two or more libraries on the same page, but only 
about a same flexibility for its instance as for JSF factories, 
handlers, and everything else.
>
>> 3) Connect 'status' component to library so in can display request
>> status for all or only selected components.
>
> You can, I think, do that now with the event system. That was the whole
> point of the event system.
>
>> 4) Log AJAX execution. At the development stage, application developer
>> can use special 'debug' component to analyse requests and updates.
>
> You should be able to do this now with the existing event structure. If
> it's missing something that you need, let us know - but the responseXML
> is included, so a monitor component should be trivial to write.
>
> I'll send additional comments once I have some time.
>
> Jim