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

[Jim Driscoll]

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.

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.


>> 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.

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.

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.

> 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