[jsr-314-open] JSF 2.1 ajax spec enhancements

[Jim Driscoll]

Re:

Delay, timeout, queuesize.

There are two ways to handle this behavior - we've discussed both over 
the last year.

The first approach would be to simply specify them, as you do here.  (It 
was certainly my first impulse to do this same thing.)

There are a few problems with approach -

The biggest one is that it conflicts with the current behavior of 
RichFaces.  They have a very... rich...  request delay and aggregation 
infrastructure.  Specifying something that's less than what they 
currently do, without an extension mechanism, is probably not going to work.

The second problem is the rather high level of implicit complexity that 
underlies your proposal.  How many queues are there?  Are we talking 
connection queues, or request queues?  How can you query the queues? 
Can you tell which queue any given request goes to?  What about user 
driven aggregation?   What about multi-field shared queues?

So, in reaction to these problems, I proposed a second approach, a 
generic extension.  It has two primary drawbacks - it's more complex 
(though it should be hidden from the general purpose usecase), and it's 
still not written up.  (This last drawback is it's most serious one :-).

I promised to write up my proposal before the break, but was sidetracked 
by a number of other urgent matters.  I'll try to get it written up this 
week.

Jim

On 12/22/09 7:33 AM, Ganesh wrote:
> Hi,
>
> Here's my wishlist for JSF 2.1 ajax spec enhancements. All proposed
> enhancements are pure client side (js) stuff. Still they are basic
> features that make a lot of difference in practical use.
>
> If there are no objections I will open spec enhancement requests
> for JSF 2.1 on the 4 parameters and 2 functional clarifications
> described hereafter.
>
>
> First i'd like to see 4 parameters added to f:ajax as well as to
> jsf.ajax.request. All 4 of them are optional and default to the
> 2.0 behaviour to guarantee backward compatibility:
>
> 1. delay: Number of milliseconds before an ajax request is issued. If
> another ajax request comes in before the end of the delay the prior one
> is discarded. Very important one for onkeyup events in autosuggest boxes
> to avoid bombing the server down.
>
> 2. timeout: Number of milliseconds before a xhr request is cancelled.
> We've already got
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=682
> on this one.
>
> 3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
> for most usages a queue size of 1 is appropriate. This param makes the
> queue size configurable. Follow up requests would replace prior request
> if the queue is full.
>
> 4. pps (true/false): Only the components named in the "execute"
> parameter are processed in phase 2-4, but the spec insists on submitting
> all elements included in a form. If pps is set to true submission is
> reduced to the form params named in execute.
> This is a performance feature that can boost speed on large
> pages.
>
>
> There are also 2 functional clarifications I want to propose. Mojarra
> and MyFaces partly differ in this, so I think we need to
> clarify.
>
> runscripts: If a piece of XHTML comes in via xhr and contains <script>
> tags the ajax engine should automatically trigger execution of
> these scripts. This is important if you want to replace a js function
> or if the scripts somehow initialize UI elements. It depends on a
> combination of the js replacement code
> (innerHTML/adjacentHTML/contextualFragment/...) and the browser
> platform whether the browsers automatically run these scripts,
> IE mostly doesn't run them FF mostly does so. The ajax engine should
> know whether the browser does automatically run the scripts and if it
> doesn't they should be triggered via js.
>
> applystyles: If a piece of XHTML comes in via xhr and contains <style>
> tags the ajax engine should automatically apply the styles to the page.
> Again some browser engines with some replacements methods do apply
> the styles others don't and the ajax engine should be responsible
> to guarantee it.
>
> Best regards,
> Ganesh
>
>
>