[ http://issues.apache.org/jira/browse/MYFACES-187?page=comments#action_66241 ] Martin Zdila commented on MYFACES-187: --------------------------------------
Hi > Additionally, I don't understand Martin Zdilas comment - in fact his > description is exactly how the implementation should behave. I hope you read my comment also with the fix below. Is it really how the implementation should behave? Then I think this behaviour is wrong. When the form is submitted with errors, all inputs should contain the submitted values without any regard of their validity. (I didn't read the specs but I consider this behaviour as matter of course.) In our case it doesn't because the second h:inputText contains the value from the last valid form subission instead from the previous post. Here goes again the (fixed) testcase: 1. enter a string to first and second h:inputText and submit the page 2. page is submitted with no validation errors, both h:inputText are filled in 3. delete the text from both h:inputText components 4. page is submitted with validation errors. The first h:inputText is blank with an error - this behavior is OK, but the second h:inputText contains the text endered in the first step - but it is WRONG - it should stay blank (as it was in 3th step) 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
