Am 11.12.12 22:41, schrieb Edward Burns:
>>>>>> On Mon, 3 Dec 2012 11:35:24 +0100, Werner Punz <werner.punz_at_gmail.com> said:
> WP> I found an issue with the dedicated call to getClientWindow as is.
>
> WP> javax.faces.ClientWindow Call jsf.getClientWindow(), passing the current
> WP> form. If the return is non-null, it must be set as the value of this
> WP> name/value pair, otherwise, a name/value pair for client window must not be
> WP> sent.
>
> WP> Now if someone decorates getClientWindow to return null, and we are in the
> WP> fileupload case, the clientWindow always will be sent nevertheless because
> WP> of the hidden field present.
> WP> The same goes if there is a clientWindow hidden field present, it will be
> WP> encoded and sent. (Note the implementation detail for the hidden field
> WP> present case is always to alter the value of the hidden field temporarily
> WP> before sending and reset it after sending)
>
> WP> The better solution would be always to send the result of getClientWindow
> WP> and in case of null sending a dedicated empty or marker string and have it
> WP> resolved on the server as no clientWindow id. This would work in the
> WP> fileupload case and the normal case.
>
>>>>>> On Mon, 3 Dec 2012 12:42:19 +0100, Werner Punz <werner.punz_at_gmail.com> said:
> WP> The alternative would be to drop the call to jsf.getClientWindow entirely
> WP> like it was done before.
> WP> I am still undecided whether it is a good idea to call jsf.getClientWindow,
> WP> due to the problems it imposes with the form handling.
>
> WP> What do the component authors say to this, is a decoration of
> WP> jsf.getClientWindow necessary?
>
> I am willing to make the change you suggested to the jsdoc spec for
> javax.faces.ClientWindow. Before I take the time to do it, I want to be
> sure you think it's necessary, Werner.
>
> Is it necessary?
>
> Ed
>
First of all sorry for the delay I simply have missed the answer.
I gave the issue another round of prototyping today.
Hia, I now have a working prototype for the current state of the spec.
The trick simply is to disable the viewstate hidden fields dynamically
if not viewstate can be determined (which in that case can only happen
if getViewState is decorated).
So I guess the spec holds up and jsf.getClientWindowId can be decorated.
So I have to apologize for the change request. I tried to prototype the
spec out and hit a dead end which I now have resolved.
Werner