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

[Werner Punz]

Yes, actually to give Ganesh additional credits here, the partial submit
code stems
from the stuff he and Alex were doing in the J4Fry project. My original idea
was just to implement the specs as defined, but given their experience in
the J4Fry project
he proposed to add that stuff, and I was happy to get it in. We have some of
those hidden things
in there (like the queue control stuff modulariuzation, queue control to
some degree etc...)
the partial submit is not really that much of a change and definitely has to
go into the next spec.

(As well as the option for additional transport layers in my opinion,
because the current approach
blocks fileuploads or moves them into their own framework layer)

Werner


On Tue, Dec 22, 2009 at 9:37 PM, Ganesh <ganesh at j4fry.org> wrote:

> No, it isn't. I have implemented this option in the MyFaces
> JavaScript and tested it against Mojarra and it works just
> fine. In MyFaces it's hidden because we didn't want to
> bend the spec.
>
> Best regards,
> Ganesh
>
> Lincoln Baxter, III schrieb:
>
>  What I (rather poorly) alluded to, was the fact that we will need to
>> decide how to handle fields defined in the form that are not passed
>> back during the partial page submit.
>>
>>  Actually, now that I think about this more, I don't think it would be
>> much different at all than the current behavior of partial view
>> traversal that we do now for Ajax submits. Since we already ignore the
>> other fields, it would most likely be a trivial (client side) change
>> to send only the specified fields. Is there any part of the
>> server-side Ajax processing that depends on having all form fields in
>> the request? I don't believe so (at least not in the spec).
>>
>> --Lincoln
>>
>>
>>
>> On Tue, Dec 22, 2009 at 3:18 PM, Ganesh <ganesh at j4fry.org> wrote:
>>
>>> +1 for partialSubmit instead of pps.
>>> Actually I do not understand why the 2.0 spec insists on
>>> submitting the complete form, not only the elements listed
>>> in execute, but backwards compatibility would probably require leaving it
>>> as
>>> default.
>>>
>>> I don't completely understand what you are saying with
>>> "This attribtue is specific to any Ajax request in a given form",
>>> Can you please elaborate on this?
>>>
>>> Lincoln, can be please give some details on the
>>> "implications for validation and other view processing"
>>> you see with this attribute?
>>>
>>> Best regards,
>>> Ganesh
>>>
>>>    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?
>>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100120/a86f9879/attachment.html