[ http://issues.apache.org/jira/browse/MYFACES-632?page=comments#action_12330614 ]
Tara Peltier commented on MYFACES-632: -------------------------------------- [originally posted to myfaces mailing list, cloned the original issue and appended this as requested by Martin Marinschek ] I've been using MyFaces 1.0.9 and just yesterday upgraded to 1.1.0, and have found a significant difference in behavior. I have a form with a single inputText component and a dataTable with several inputText components. When I submit the form using an immediate commandButton, I expect to get the submitted values back for both the stand-alone inputText and the dataTable inputTexts when the screen is redisplayed. As I understand it, this is the behavior dictated by the spec: (Apply Request Values 2.2.2): At the end of this phase, all EditableValueHolder components in the component tree will have been updated with new submitted values included in this request (or enough data to reproduce incorrect input will have been stored, if there were conversion errors). In addition, conversion and validation will have been performed on EditableValueHolder components whose immediate property is set to true. This works as I expected in 1.0.7 and 1.0.9 - the submitted values are redisplayed after an immediate commandButton for both the standalone and the dataTable inputText components. However, in 1.1.0, the submitted values IN THE DATATABLE are lost when the screen is redisplayed - the stand alone inputText component correctly displays the submitted value again. The Sun RI implementation has this bug also, where the inputs in a dataTable do not correctly redisplay submitted values, and Sun has acknowledged it as a bug (https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=73) Am I correct in believing this is a bug in 1.1.0? I have searched the past mailing list, and found a related discussion from August (http://issues.apache.org/jira/browse/MYFACES-277). Here is my test form to exhibit this issue: <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%> <html> <body> <f:view> <h:form id="form"> <h:inputText id="single" value="#{realData.singleData}" /> <h:dataTable id="dtable" value="#{realData.rows}" var="row"> <h:column id="column"> <h:inputText id="input" value="#{row.value}"/> </h:column> </h:dataTable> <h:commandButton action="#{realData.doAction}" value="Immediate" immediate="true"/> <h:commandButton action="#{realData.doAction}" value="Not" immediate="false"/> </h:form> </f:view> </body> </html> > CLONE -using a button with immediate on a form with a dataTable component > ------------------------------------------------------------------------- > > Key: MYFACES-632 > URL: http://issues.apache.org/jira/browse/MYFACES-632 > Project: MyFaces > Type: Bug > Reporter: Tara Peltier > Assignee: Mathias Broekelmann > Fix For: 1.1.0 > > i'm using a form that contain a dataTable component . There is also a button > that modify the model of the table with > an array of only one element with the single fields initialized to "" (String > fields) and has the attribute immediate set > to true. When the form is rendered after i have pressed the button with the > immediate attribute set to true ,the value that i obtain is the value > submitted and not the value of the model. > I have found the following workaround that i have put on a properties of the > row of the table that is called on the rendering phase: > if (component.getSubmittedValue() != null && > arrayOfRecord[model.getRowIndex()].getCodice() != null && > > !component.getSubmittedValue().equals(arrayOfRecord[model.getRowIndex()].getCodice())) > { > > component.setSubmittedValue(arrayOfRecord[model.getRowIndex()].getCodice()); > } > I have used the value of the model and not the component.getValue() because > also this was not the same > of the value of te model. > I can try to create a simple case if it is necessary o the problem is not > clear. > The problem seems the same of the issue 187 (that it is closed) but i i have > tested the night builds and nothing > changed. However in the release notes of the night builds the issue is not > reported as solved. -- 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
