Yes, actually to give Ganesh additional credits here, the partial submit code stems <br>from the stuff he and Alex were doing in the J4Fry project. My original idea<br>was just to implement the specs as defined, but given their experience in the J4Fry project<br>
he proposed to add that stuff, and I was happy to get it in. We have some of those hidden things<br>in there (like the queue control stuff modulariuzation, queue control to some degree etc...)<br>the partial submit is not really that much of a change and definitely has to go into the next spec.<br>
<br>(As well as the option for additional transport layers in my opinion, because the current approach <br>blocks fileuploads or moves them into their own framework layer)<br><br>Werner<br><br><br><div class="gmail_quote">
On Tue, Dec 22, 2009 at 9:37 PM, Ganesh <span dir="ltr"><<a href="mailto:ganesh@j4fry.org">ganesh@j4fry.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
No, it isn't. I have implemented this option in the MyFaces<br>
JavaScript and tested it against Mojarra and it works just<br>
fine. In MyFaces it's hidden because we didn't want to<br>
bend the spec.<br>
<br>
Best regards,<br>
Ganesh<br>
<br>
Lincoln Baxter, III schrieb:<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What I (rather poorly) alluded to, was the fact that we will need to<br>
decide how to handle fields defined in the form that are not passed<br>
back during the partial page submit.<br>
<br>
Actually, now that I think about this more, I don't think it would be<br>
much different at all than the current behavior of partial view<br>
traversal that we do now for Ajax submits. Since we already ignore the<br>
other fields, it would most likely be a trivial (client side) change<br>
to send only the specified fields. Is there any part of the<br>
server-side Ajax processing that depends on having all form fields in<br>
the request? I don't believe so (at least not in the spec).<br>
<br>
--Lincoln<br>
<br>
<br>
<br>
On Tue, Dec 22, 2009 at 3:18 PM, Ganesh <<a href="mailto:ganesh@j4fry.org" target="_blank">ganesh@j4fry.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
+1 for partialSubmit instead of pps.<br>
Actually I do not understand why the 2.0 spec insists on<br>
submitting the complete form, not only the elements listed<br>
in execute, but backwards compatibility would probably require leaving it as<br>
default.<br>
<br>
I don't completely understand what you are saying with<br>
"This attribtue is specific to any Ajax request in a given form",<br>
Can you please elaborate on this?<br>
<br>
Lincoln, can be please give some details on the<br>
"implications for validation and other view processing"<br>
you see with this attribute?<br>
<br>
Best regards,<br>
Ganesh<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4. pps (true/false): Only the components named in the "execute"<br>
parameter are processed in phase 2-4, but the spec insists on<br>
submitting all elements included in a form. If pps is set to true<br>
submission is reduced to the form params named in execute.<br>
This is a performance feature that can boost speed on large<br>
pages.<br>
<br>
<br>
What does pps stand for? Why are we submitting all elements when we only<br>
process a subset? Is that the best default?<br>
<br>
This attribtue is specific to any Ajax request in a given form, not<br>
specific to an ajax request that results from an f:ajax tag, so does the<br>
attribute belong on f:ajax? What if two f:ajax tags set the attribute to<br>
different values in the same form?<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br>