11:58 a.m.
2009/12/22 Ganesh <ganesh(a)j4fry.org>
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.
The delay attribute causes two things to happen: delay the request, and
(potentially) cancel the request. The attribute name identifies the former,
but does not imply the latter. I think that could be confusing.
I'm also not sure that we want to tightly couple delay and cancellation. I
want to control each individually, for example, I have a use case with an
autoSuggest composite component where I add a delay to an Ajax call that
hides a listbox, and I want don't want that Ajax call cancelled if another
Ajax request comes in before the delay is over.
Perhaps two attributes? "delay" and a boolean attribute that controls
whether the request is canceled if another Ajax request comes in before the
delay expires. A good name for the second attribute would be difficult to
come up with.
Also, there's the issue of whether we want to allow only certain types of
Ajax requests (for example only requests fired by the same component) to
cause the cancellation of a previous request with a delay.
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=6... this one.
+1
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.
I'm not sure this is appropriate for an f:ajax tag attribute. It sets a
application-wide flag for Ajax behaviors (correct?), and is not specific to
the Ajax request to which the f:ajax tag is assocated.
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.
What does pps stand for? Why are we submitting all elements when we only
process a subset? Is that the best default?
This attribtue is specific to any Ajax request in a given form, not specific
to an ajax request that results from an f:ajax tag, so does the attribute
belong on f:ajax? What if two f:ajax tags set the attribute to different
values in the same form?
There are also 2 functional clarifications I want to propose. Mojarra and
MyFaces partly differ in this, so I think we need to
clarify.
Sorry, I'm confused. Are runscripts and applystyles f:ajax tag attributes?
If so, do the attributes affect only the Ajax request that f:ajax fires, or
is it an app-wide setting for all Ajax requests?
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.
I understand the desire for this, but this opens a pretty big security hole,
doesn't it? Do we need to do anything about that?
david
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