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