[ 
https://issues.apache.org/jira/browse/MYFACES-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614595#comment-13614595
 ] 

Leonardo Uribe commented on MYFACES-3702:
-----------------------------------------

I don't remember if there is an issue created in the spec issue tracker:

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC

In theory there is a dependency between the row state and the data model. In 
this case, the description in the javadoc must be respected. 

The only alternative is do something in tomahawk t:dataList or t:dataTable to 
alter the default behavior, but anyway it is necessary to specify the 
conditions over the dataModel is cleared in encodeBegin(). One idea could be 
introduce an attribute that instead check for a FacesMessage in the stack, it 
checks if there is a validation error (FacesContext.isValidationFailed() ), and 
if that so do not clear the dataModel, otherwise do it. We need a good name for 
that attribute too. I think something like that could work.
                
> ui:repeat is caching its data model if error occurs 
> ----------------------------------------------------
>
>                 Key: MYFACES-3702
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3702
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.1.10
>            Reporter: dennis hoersch
>
> ui:repeat caches its data model. Usually it it is cleared before rendering. 
> But not if there are any errors in faces context. 
> Why is it not cleared then?
> That causes a problem in the following scenario:
> We have an ui:repeat that iterating over a list of more detailed error 
> messages of an object on the page. This list is empty in the start of an 
> request. While invoking an action on the page error messages are added to the 
> faces context to be shown on the page. Additionally some more detailed 
> information is stored to be shown directly with that object.
> But they won't appear because the empty list is cached in the ui:repeat's 
> data model.
> I could reproduce it with the following more general example: The first 
> button creates an info message which will be shown by the ui:repeat. The 
> second button creates an error message and nothing is rendered through the 
> ui:repeat.
> Testpage.xhtml
> <his:form id="testForm">
>   <h:commandButton value="Create info message" 
> action="#{testController.createInfoMessage()}" />
>   <h:commandButton value="Create error message" 
> action="#{testController.createErrorMessage()}" />
>   <br/>
>   UI:Repeat:
>   <ui:repeat var="item" value="#{facesContext.getMessageList()}">
>     FacesMessage #{item.severity} // #{item.summary}
>   </ui:repreat>|<br/>
>   Has Messages: #{not empty facesContext.getMessageList()}|
> </his:form>
> TestController
> public void createErrorMessage() {
>   MessageUtils.addMessage(FacesMessage.SEVERITY_ERROR, "Oh no, an error!", 
> new Object[] {});
> }
> public void createInfoMessage() {
>   MessageUtils.addMessage(FacesMessage.SEVERITY_INFO, "Just an information.", 
> new Object[] {});
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to