[ 
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

        

Reply via email to