>>>>> 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
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/