Limpando a árvore de componentes – Rafael Ponte
Previous Post Post anterior:Problema do rendered dinâmico com JSF
Next Post Hibernate Efetivo – erros comuns e soluções
25 Replies to "Limpando a árvore de componentes"
Altieres says: 11 anos atrás
Ótimo post Rafael!!
Utilizo sua 'maneira educada' de limpar a árvore de componentes e nunca tive problemas.
Fugindo um pouco do tema.
Entender o ciclo de vida do JSF não é uma tarefa fácil e você sempre fala do Ciclo de Vida, esses dias em uma Thread do grupo JSF vi que algumas pessoas pediram pra você fazer um Post sobre ciclo de vida, reforço o pedido dos amigos da Thread. (Sei que seu tempo deve ser curto, mais faz um esforço aii)
Eae Rafael, blz? Mais um post simples e objetivo como sempre. Lendo teu post lembrei que "esses dias" vi na lista do EG do jsf rolou esse assunto (mas está parado lá) http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-06/message/0
Fala Gilliard,
Eu não tinha visto essa thread na lista do EG, para falar a verdade eu nem mesmo estou inscrito na lista.
Ao ler a thread eu diria ao Cagatay que isso se deve ao modelo "pull" do faces e que ele não pode evitar de "cachear" o local value pois o faces não tem como garantir que o managed bean estará num estado válido ao pular para a RENDER RESPONSE, isto é, no último estado antes da requisição.
No mais, a thread me fez lembrar do antigo post da Apache sobre o problema, http://wiki.apache.org/myfaces/ClearInputComponents . Eu já atualizei meu post e coloquei o link, pois com certeza é um artigo antigo e muito importante sobre o assunto.
Desculpe-me pela ignorância, Gilliard, mas a lista do EG é aberta ao pública?
Levy Moreira says: 11 anos atrás
Como sempre um ótimo post Rafael, como disse o amigo acima sei que seu tempo é pouco e até já fazia um tempo que não postava, mas sempre que há um novo post vira referencia, como o do redered dinamico, que onde se fala nesse 'problema' existe junto um link pro seu post, gostaria de reforçar o pedido de um post sobre o ciclo de vida do jsf, talvez nem de pra cobrir tudo em um único post, mas seria de grande ajuda e mais um post de referencia na área.
L. Casiano says: 11 anos atrás
Excelente post, gostei mesmo muito.
Alexa Shotebenada says: 10 anos atrás
Mais do que uma simples "viagem", como se costuma chamar algo diferente, à preciso muito estudo e entendimento do público alvo para determinar como uma peà a especà fica vai ficar.
Renan says: 10 anos atrás
Legal seus posts Rafael, coloque um sobre padronização e boas praticas do JSF e JPA/Hibernate juntos.
lixo says: 9 anos atrás
Enrolou com um texto inutil e nao falou como limpa a droga do formulario
Raphael Lacerda says: 9 anos atrás
Tem bater pra tudo! E ainda não saber ler!
Recomendo muito esse post para os meus alunos.. Se for algum deles vou dar eh porradaaa!
Rodnei Vete says: 8 anos atrás
Estou apanhando deste erro faz algum tempo. Acompanhei toda thread no GUJ e seu post. Tenho a dizer que vc é o cara!! rsss
Mas no meu caso não consegui resolver.
Eu tenho um dialog que o conteudo é montado dinamicamente através de 3 listas (uma dentro da outra). Onde na primeira uso pra montar um accordionPanel, dentro deste accordion eu itero sobre a segunda lista (ui:repeat) onde escrevo algumas coisas e por fim crio um datatable usando a terceira lista. Dentro deste datatable eu tenho alguns inputText cujo value é apontado para os itens da ultima lista. Ocorre que mesmo fazendo a limpeza da arvore conforme vc mencionou não resolve.
Se ficou confuso posto o codigo pra vc ver.
Bem estranho nenhuma destas soluções terem funcionado com você, mesmo se tratando de uma caso mais complexo como é o seu.
Você está limpando a árvore de componentes e os dados no managed bean também? Pois é necessário limpar dos dois.
Outra coisa, se puder postar o código, poste no http://gist.github.com/, pois talvez aqui nos comentários não fique bem formatado e pode nem aparecer como deveria.
Olha ai Rafael o código. Estou usando a opção 2 para limpar os componentes. Quanto aos dados do ManagedBean eu atualizo a lista com dados vindos do banco (novos valores).
<p:accordionPanel multiple="true"
value="#{entrevistaCartaCreditoMBean.lstSessoesDocumentos}"
var="sessao">
<p:tab title="#{sessao.sessao}">
<ui:repeat var="subSessao" value="#{sessao.subSessao}">
<h:outputLabel value="#{subSessao.subSessao}" />
<h:dataTable var="documento" value="#{subSessao.documentos}">
<h:outputLabel styleClass="ui-icon ui-icon-help"
title="#{documento.documento.descricao}" />
disabled="#{entrevistaCartaCreditoMBean.desabilitar}"
value="#{documento.entregue}" />
<h:column headerClass="cssColumnDesc">
<h:outputLabel value="#{documento.documento.nome}" />
#{rotulo.dataEntrega}
<p:inputMask styleClass="masked_calendar"
mask="99/99/9999" value="#{documento.dataEntrega}" disabled="#{entrevistaCartaCreditoMBean.desabilitar}">
<f:convertDateTime pattern="dd/MM/yyyy" timeZone="America/Sao_Paulo" locale="pt_BR" />
#{rotulo.ilegivel}
value="#{documento.ilegivel}" />
O que não está limpando são os inputs dentro dos datatables?
Quando provoco algum erro de validação em algum input e depois fecho o dialog e abro com outros dados, ele mantem os mesmos dados do registro que deu erro. Ele não atualiza o datatable…
Pingback: @ViewScoped, o ovo e a galinha | Rafael Ponte
Se não me engano o componente de dialog é criado no lado cliente (browser), ou seja, após criado ele fica somente escondido.
O que você precisa fazer é, após limpar a árvore de componentes, repintar o componente de dialog antes de exibi-lo para que as mudanças façam efeito no lado cliente.
Quando vc diz "repintar", é o mesmo que usar o atributo update?
Sim, sim. É o mesmo que o atributo update no Primefaces ou render do f:ajax ou reRender no Richfaces.
Eu faço isso, tanto que quando não provoco erro de validação a pagina aparece atualizada com os dados do outro registro. O problema ocorre quando da erro e ai clico em outro registro, neste momento o que estava sendo exibido quando deu o erro continua, ou seja, não atualiza.
Você está limpado o bloco (ou h:form) de componentes correto? Digo isso, pois normalmente se utiliza um formulário para página principal e um para cada dialog.