[
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