Clear a Bean variable from the JSF page

Question

I have a page with some iteration loops inside my page JSF and then I’d like to know how I do to after each loop clear that attribute from the page.

To be clear, I know that when rendering a page sometimes a method is called a few times, so one creates a lista for example and fills it if it is empty.

public List<Long> buscarLojas() {
    if (NullUtil.isNull(this.idsLoja)) {
        this.idsLoja = new ArrayList<Long>(this.getPojo().getRelatorioExtratoLojista().keySet());
    }
    return idsLoja;
}

In the above code is done, but I would like to know if it has how to clear after loop execution ui:repeat

Follow my page code, this omitted most columns.

<ui:param name="lojas" value="#{bean.buscarLojas()}"/>
<ui:repeat var="loja" value="#{lojas}">
    <ui:param name="filiais" value="#{bean.buscarFilial(loja)}" />
    <ui:repeat var="filial" value="#{filiais}">
        <ui:param name="atendentes" value="#{bean.buscarAtendente(loja, filial)}" />
        <ui:repeat var="atendente" value="#{atendentes}">
            <ui:param name="propostasStatus" value="#{bean.buscarPropostaStatus(loja, filial, atendente)}" />
            <ui:repeat var="propostaStatus" value="#{propostasStatus}">
                <ui:param name="objetos" value="#{bean.buscarObjeto(loja, filial, atendente, propostaStatus)}" />
                <p:panelGrid
                    id="panelGridRelatorioExtratoLojista" 
                    styleClass="panelGridCenter gridNoBackground" 
                    style="width: 100%; white-space:nowrap;">
                    <f:facet name="header">
                        <p:row>
                            <p:column styleClass="columnLeft" colspan="12">
                                <p:outputLabel value="#{bean.criarTituloTabela(objetos[0][4], objetos[0][5], objetos[0][6], objetos[0][3])}"/>
                            </p:column>
                        </p:row>
                        <p:row>
                            <p:column>
                                <p:outputLabel value="Classificação"/>
                            </p:column>
                        </p:row>
                    </f:facet>
                    <ui:repeat var="objeto" value="#{objetos}">
                        <p:row>
                            <p:column>
                                <p:outputLabel value="#{objeto[7]}"/>
                            </p:column>
                    </ui:repeat>
                </p:panelGrid>
                <br/>
            </ui:repeat>
        </ui:repeat>
    </ui:repeat>
</ui:repeat>

The structure that houses the data is this:

private Map<Long, Map<Long, Map<Long, Map<Integer, List<Object>>>>> map;

Answer 1

Summary of the conversation with the OP in chat

Original problem: Clear data

OP was storing all query data and various projections in a Managed Bean @SessionScoped. Memory consumption was beating at over 1.5GB, generating a Markup of over 130 MB for a single request. The render time was more than 10 minutes.

The original requirement of the OP was that the filters were maintained through requests, so I recommended the following solution:

• FiltroPropostaBean -> Contains only filter parameters stored in session (new Managed Bean)
• PropostasBean -> Bean Request or ViewScoped that uses Filter bean data to query.

With this structure the data only lives long enough to be rendered, avoiding memory waste.

Model and projections

The original PO code used a strategy with ResultTransformer to create a projection:

Map<Long, Map<Long, Map<Long, Map<Integer, List<Object>>>>> map;

That was the pure exit of a query after their application Resulttransformers.

As this structure was not easily navigated by the OP, he ended up creating several projections of the projection. This is the reason of the method buscarLojas, buscarFilial, etc. With five repeaters nested these methods were called several times, with great processing impact.

Thus, the issue of OP had more to do with design than anything else.

Organizing the data with Dtos it is possible to write simpler code for the view as well as remove the projection methods.

E.g., a single method that returns a List<GrupoPropostasDTO>.

class GrupoPropostaDTO {
    private Loja loja; 
    private Filial filial; 
    private Atendente atendente;
    private Loja<Proposta> propostas; 
    // Getters and setters
}

Solves both problems. This transformation can be done in an intermediary layer of services or in a @PostConstruct of ProspotaBean. Thus a single transformation is made by request and the view does not break the MVC by calling methods to calculate projections.

Paging

Finally, even with Dtos the amount of data is still massive. This can be solved with Paging.

Good Practices

While modern versions of JSF allow the use of several interesting tricks, it’s good to consider before using something that breaks the MVC standard, as well as good development practices:

• Keep the layer of view dumb. As far as possible the role of the view should be to only display data, make calls to complex methods in the view is a bad Smell.
• Choose the correct scope. The less state the better. Not everything can be done 100% Stateless, but the session scope should not be the default choice.
• Design your model layer well. A good model solves 99% of your problems.
• Controllers (or in the case of JSF the glue layer in Managed Beans) should remain simple. Heavy controllers are symptoms of views doing more than they should and layer services / poorly designed model.