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(a)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?