Hi Werner - On Fri, Feb 12, 2010 at 2:28 AM, Werner Punz <[email protected]> wrote: > Werner Punz schrieb: > Ok I shot over the top a little bit early, the problem with file input is > that you cannot cover it within the bounds of XHR at all you have to revert > to an iframe transport.
Yep. I raised this requirement a number of times as well since it is a requirement for both Trinidad and ADF Faces. Actually, my hope was that jsf.ajax.request() API was sufficiently generic to allow alternate transport implementations and I had assumed that the JSF implementations would be able to provide iframe-based postback support as an implementation detail. However, Andrew Robinson recently pointed out that there is one case where the JSF client-side API introduces an XHR dependency: jsf.ajax.response() expects an XHR object, which it uses to grab the responseXML. FWIW, Jim logged the following spec issue to track the general requirement: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=647 I have updated the issue with a comment about the jsf.ajax.response() XHR dependency. Are you aware of other such dependencies? If so, we should capture these in the spec issue as well. Note that it still seems possible for JSF implementations to provide iframe-based postback solutions, though might require a bit of hackery... Since the jsf.ajax.response() implementation expects to be able to retrieve the responseXML off of the XHR object, one possible approach might be for jsf.ajax.request() to mock up its own pseudo-XHR object which provides access to the response document from the iframe. Andrew R actually thought of this a way to allow us to delegate back to jsf.ajax.response() in Trinidad in the case where we use Trinidad's iframe-based postback mechanism. Perhaps if this works out well, we can incorporate such a solution back into MyFaces? Andy
