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

[Lincoln Baxter, III]

pps = partial page submit

+1 to delay and timeout for now, not sure about queue size, and PPS
would have implications for validation and other view processing, so
that will need a lot of thought.

On Tue, Dec 22, 2009 at 12:58 PM, David Geary
<clarity.training at gmail.com> wrote:
> 2009/12/22 Ganesh <ganesh at 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=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
>>
>>
>>
>
>