On Wed, Nov 7, 2012 at 10:19 PM, Edward Burns <edward.burns_at_oracle.com>wrote:
> >>>>> On Wed, 7 Nov 2012 08:47:37 -0800, Edward Burns <
> edward.burns_at_oracle.com> said:
>
> >>>>> On Wed, 7 Nov 2012 10:23:00 +0100, Werner Punz <
> werner.punz_at_gmail.com> said:
> WP> On Tue, Nov 6, 2012 at 6:24 PM, Edward Burns <edward.burns_at_oracle.com
> >wrote:
> >>> >>>>> On Mon, 5 Nov 2012 10:37:02 +0100, Werner Punz <
> werner.punz_at_gmail.com> said:
>
> WP> Hi Ed here is a small comment on the jsdocs in conjunction with the
> file
> WP> uploads:
>
> WP> Normal Ajax Part:
> WP> Set the request header with the name: Faces-Request and the value:
> WP> partial/ajax.
>
> WP> That is not possible in case of the iframe request because we cannot
> WP> set request headers. with iframe requests, we need another marker
> WP> here for the server to identify that this is an ajax request coming
> WP> in.
>
> WP> Normally the parameter javax.faces.partial.ajax true Should be
> WP> enough to identify that the request is an ajax request in that
> WP> case. But the sentence "*but the request must be sent with all the
> WP> parameters that a JSF XMLHttpRequest would have been sent with*"
> WP> cannot hold up entirely due to the limitations of the iframe method
> WP> regarding header parameters.
>
> EB> We already require javax.faces.partial.ajax true is sent. The reason
> we
> EB> use the header approach in the first place can be seen from this mail
> EB> from Jim Driscoll from 2008:
>
> EB> >>>>> On Tue, 16 Dec 2008 17:44:54 -0500, Jim Driscoll said:
>
> JD> Changed the PartialViewContext to use Headers, rather than parameters,
> JD> since isAjax is getting called before the view is initialized. That
> JD> means that we can't access Params, since that prevents setting the
> JD> character encoding on the request when the view is initialized.
>
> EB> I would think this restriction would also be present when sending an
> EB> "ajax" request with the hidden inline frame. Is there some other way
> EB> the server can detect the inline frame case so that it can treat it as
> EB> "ajax"?
>
> WP> To my knowledge the iframe method has the limitations of a normal
> WP> form post hence you cannot tamper with the request header, the only
> WP> way out of it is not to use iframes but xhr level2 elements for the
> WP> multipart upload. But those are only supported in new browsers (aka
> WP> even IE9 is not supporting it ie10 does however) and also xhr level2
> WP> still is a w3c working draft.
>
> EB> I am takeing XHR level 2 off the table. There is no need to bring
> EB> anything about XHR level 2 up again during JSF 2.2.
>
> I agree here, although I prefer xhr level2 over iframe due to being ajax
and since it is really easy to use,
I dont think it makes sense to integrate it as enforced transport layer
given its beta status. XHR Level2 at best should be optional if the browser
supports it which is only the newest IE and the rest of all browsers modern
browsers
So the best bet is to leave the spec open for alternative transport layers
which already is done by Eds jsdoc.
> EB> As established above, we already require javax.faces.partial.ajax true
> EB> to be sent. Given Jim Driscoll's proviso that we can't access the
> EB> params at the point in time when we need to, do you think it would be
> ok
> EB> to modify the spec for PartialViewContext.isAjaxRequest() [1] so that
> we
> EB> check for the query param if and only if the header is not present?
> EB> The header will always be present on a proper ajax request, and the
> EB> param will always be present on a proper ajax request *and* on an
> inline
> EB> frame "ajax" request.
>
>
EB> Will that work, Werner ?
Good question, it comes down to the problem that isAjaxRequest is called
before initView where the encoding is set, right?
The question is, is this an implementation isssue?
I just debugged into MyFaces here the setCharacterEncoding is done
before the first isAjaxRequest is called.
The workflow is following
a) call initView first which sets the encoding
b) isAjaxRequest is called later first at the system event stage post
initView.
So for MyFaces the encoding issue does not seem to be a limitation and the
strategy definitely works. But I dont know how Mojarra behaves.
Therefore a question back, would it be possible to shift the first
isAjaxRequest call after the initView call for Mojarra
so that the request encoding is set before to bypass the limitation? Or
does Mojarra behave like that anyway and Jim just wanted to leave the door
open here for future implementation details?
Werner
> EB> Ed
>
> EB> --
> EB> | edward.burns_at_oracle.com | office: +1 407 458 0017
> EB> | homepage: | http://ridingthecrest.com/
>
> EB> [1]
> https://maven.java.net/service/local/repositories/snapshots/archive/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20121107.093348-90-javadoc.jar/!/javadocs/javax/faces/context/PartialViewContext.html#isAjaxRequest()
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>