ahh, now I see, the description of the test-case was just not very clear ;)
well, that is of course a wrong behaviour - I will try it out. regards, Martin On 5/25/05, Martin Zdila (JIRA) <[email protected]> wrote: > [ > 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 > >
