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

2009/12/22 Ganesh <ganesh(a)j4fry.org&gt; > > 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=682 > on 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 > > >