[richfaces-issues] [JBoss JIRA] Commented: (RF-11333) rich:column sorting runs one step behind when partial state saving is disabled

Thu Sep 29 12:04:27 EDT 2011

    [ https://issues.jboss.org/browse/RF-11333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631346#comment-12631346 ] 

henk de boer commented on RF-11333:
-----------------------------------

The problem seems to be bigger than just the sorting. The root problem seems to be that without partial state saving, on a post-back the RichFaces datatable only resolves its value binding during the "{{Apply Request Values}}" phase.

This means that data that is set during "{{Invoke Application}}" will not be processed during the subsequent "{{Render}}" phase.

E.g. consider the following backing bean:

{code:title=TestBacking.java}
@ViewScoped
@ManagedBean
public class TestBacking {

    private List<String> queryResult;

    public void execute12() {        
        queryResult = new ArrayList<String>();
        queryResult.add("1 - " + new Date());
        queryResult.add("2 - " + new Date());
    }

    public void executeABC() {        
        queryResult = new ArrayList<String>();
        queryResult.add("A - " + new Date());
        queryResult.add("B - " + new Date());
        queryResult.add("C - " + new Date());
    }

    public List<String> getQueryResult() {
        return queryResult;
    }

}
{code}

and the following Facelet:

{code:title=test.xhtml}
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:rich="http://richfaces.org/rich"
>
    <h:head/>
    <h:body>    
        <h:form>

            <h:commandButton value="excecute 12" action="#{testBacking.execute12}" />
            <h:commandButton value="excecute ABC" action="#{testBacking.executeABC}" />

            <rich:dataTable value="#{testBacking.queryResult}" var="result" >            
                <rich:column>
                    #{result}
                </rich:column>            
            </rich:dataTable>

        </h:form>    
    </h:body>
</html>
{code}

With {{javax.faces.PARTIAL_STATE_SAVING}} set to false, as indicated by Bauke, the result is that clicking the first button will seem to have no result. Then clicking the second button will render the result of the first click. This happens because during the first post-back the result is not rendered, but remembered in view scope. Then during the second post-back this data is obtained before new data is generated and subsequently used for rendering. In effect the rendering is thus one-behind.

If the backing bean is changed to be request scoped, the data is simply lost and nothing will ever be rendered.

When {{javax.faces.PARTIAL_STATE_SAVING}} is set back to true, everything works as expected. I tested this with GlassFish 3.1.1 (Mojarra 2.1.3) and RichFaces 4.0.0.Final.

> rich:column sorting runs one step behind when partial state saving is disabled
> ------------------------------------------------------------------------------
>
>                 Key: RF-11333
>                 URL: https://issues.jboss.org/browse/RF-11333
>             Project: RichFaces
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: component-tables
>    Affects Versions: 4.0.0.Final
>         Environment: Mojarra 2.1.2, Tomcat 7.0.19 / GlassFish 3.1 / JBoss AS 6.0.0, Eclipse Helios SR1, Win7 x64.
>            Reporter: Bauke Scholtz
>              Labels: column, datatable, sorting
>             Fix For: 4.Future
>
>
> The {{rich:column}} sorting runs one step behind when partial state saving is disabled by 
> {code}
> <context-param>
>     <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
>     <param-value>false</param-value>
> </context-param>
> {code}
> First click on a sorting header has no effect. Any next click on an arbitrary sorting header executes the sorting as desired by the previous click.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira