[ 
http://issues.apache.org/jira/browse/MYFACES-187?page=comments#action_66235 ]
     
Martin Marinschek commented on MYFACES-187:
-------------------------------------------

Thanks for the fast response!

The problem for me is now that empty strings are now all over the place cause 
they do not get deleted out of the submitted value anymore. With this, the 
implementation thinks that a value was submitted and does not retrieve the 
component value from the back-end anymore.

Obviously a problem!

But we do have to check if setting an empty string for the UIInput value is 
necessary at all in case of the simple UIInputs (it is necessary for the 
UISelectMany items). I think we can get rid of that.

Additionally, I don't understand Martin Zlidas comment - in fact his 
description is exactly how the implementation should behave.

regards,

Martin

> UIInput.getValue can return wrong (old) value
> ---------------------------------------------
>
>          Key: MYFACES-187
>          URL: http://issues.apache.org/jira/browse/MYFACES-187
>      Project: MyFaces
>         Type: Bug
>     Versions: 1.0.9 beta
>     Reporter: Howard Abrams
>     Assignee: Martin Marinschek
>      Fix For: Nightly Build

>
> 'UIInput.getValue' will return the wrong (old) value if called between 
> validation and update phase when the submitted value is "" and the old value 
> was a non-zero length string.
> The offending code is in UIInput.validate:
>     if(submittedValue instanceof String && ((String) 
> submittedValue).length()==0)
>     {
>         submittedValue = null;
>     }
> The effect of this is that when the client submits "", the submittedValue of 
> null works it's way down to 'setValue'. This would seem correct, but 
> 'getValue' checks to see if the value is null, and if it is, it uses the 
> value binding. The end result is that 'getValue' will return the wrong (old) 
> value if called between validation and update phase becuase the model has not 
> been updated yet, but the local value has been null'd.
> Neither the spec, nor the offical JavaDoc mention this behavior. I belive the 
> code should be removed. Anyone know why it is there?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to