[ https://issues.apache.org/jira/browse/MYFACES-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115270#comment-13115270 ]
Michael Kurz commented on MYFACES-3326: --------------------------------------- I did some further investigations and the problem is the same in Mojarra. The spec doc for UIData.encodeBegin() says the following: "In addition to the default behavior, ensure that any saved per-row state for our child input components is discarded unless it is needed to rerender the current page with errors." I additionaly scanned the spec and found no mention of displaying the submitted value if it is still set in render response (which apparently is done). So what do you think: Is this a valid issue? > UIData does not preserve submitted values on immediate requests > --------------------------------------------------------------- > > Key: MYFACES-3326 > URL: https://issues.apache.org/jira/browse/MYFACES-3326 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 > Affects Versions: 2.1.3 > Reporter: Michael Kurz > Attachments: MYFACES-3326-testapp.zip > > > I have a h:dataTable component with an h:inputText component per row bound to > a list. Now I want to add a new row with a h:commandLink outside the table > via ajax. This link is immediate to avoid validation on the input components. > The problem is, that when I set the command link immediate, data the user > entered into the input components vanishes (render and execute in f:ajax are > set to the table). I did some investigations and saw that > UIData.encodeBegin() resets the state (and submitted values!) before > rendering. IMO, the submitted values must be preserved if phases 3 to 5 are > skipped. > I first thought that setting _isValidChilds to false in processDecodes if > renderResponse() is called might work. But as the link is outside and after > the table renderResponse() is not called yet at that point. I wonder what the > correct way to handle this could be? Maybe remember if processValidators() > was called on the table. If not, don't kill the state. > Btw. the same applies for ui:repeat. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira