1) Submitted Value
2) Local Value
3) Value Binding (aka model value)

** Quando você submete um formulário todos os inputs da página são submetidos como String (parâmetros de request) e na APPLY REQUEST VALUES (2a fase) este valores são setados nos seus devidos componentes de inputs como "submitted value";

** Após isso, na fase de validação (3a fase), cada componente de input tenta converter e validar seu submitted value, em caso de sucesso o componente define seu novo valor convertido como "local value" e seta para null seu submitted value, continuando assim o ciclo de vida. Em caso de erro de conversão ou validação o componente não define seu "local value" e marca o componente como invalido, que por fim pula para última fase (RENDER RESPONSE);

** Se não houver erro na fase de validação o ciclo de vida continua na UPDATE MODEL VALUES para popular o modelo (managed bean etc), para cada componente de input setado no modelo o seu "local value" é setado para null e o ciclo termina na RENDER RESPONSE exibindo os valores do modelo (através das EL's);

** Se houver submitted value então retorne-o;
** Caso contrário, se o local value é não nulo então retorne-o;
** Caso contrário, avalie a EL, ou seja, chame o getter do modelo;

1) Navegação padrão do Faces para recriar toda a viewroot (não vale retornar null);
2) Limpar de maneira educada todos os componentes de inputs;
3) Limpar os inputs de maneira "brute force" (parentComponent.getChildren().clear() - eles serão recriados na RENDER RESPONSE novamente, porém só funciona com JSF 1.x, pois o 2.x parece seguir corretamente a spec);

** Após isso, na fase de validação (3a fase), cada componente de input tenta converter e validar seu submitted value, em caso de sucesso o componente define seu novo valor convertido como "local value" e seta para null seu submitted value, continuando assim o ciclo de vida. Em caso de erro de conversão ou validação o componente não define seu "local value" e marca o componente como invalido, que por fim pula para última fase (RENDER RESPONSE);

** Se não houver erro na fase de validação o ciclo de vida continua na UPDATE MODEL VALUES para popular o modelo (managed bean etc), para cada componente de input setado no modelo o seu "local value" é setado para null e o ciclo termina na RENDER RESPONSE exibindo os valores do modelo (através das EL's);

danilo.magrini wrote:
Só fazendo uma observação aqui Rafael, o local value é setado logo após o submitted value ser convertido (se existir um converter associado) e sequer atinge o estágio de validação pois se assim fosse o local value nunca serviria pra nada já que se a conversão foi correta e a validação também então o modelo já seria atualizado e o local value passaria para null correto?

nei.junior wrote:
* Agora no momento que cliquei no botão "Editar" do nome "MARIA" ele atualizou o modelo, significa que ele executou todos os outros processos corretamente, ou seja, o "Submitted Value" e o "Local Value" estão como "NULL".
Agora porque que na tela continua errado ? Não era para vir certo ?

Obrigado por enquanto !

rponte wrote:
Nei,

Lembre-se que a árvore de componentes ficou "suja" após o erro de validação (mas especificamente os inputs do formulário), e o que você fez após clicar no botão "Voltar" foi apenas esconder o formulário (rendered=false). O formulário, independente de quantas requisições AJAX ocorram, ainda permanece "sujo" em memoria e seus componentes de inputs não são processados no ciclo de vida pois o componente parent está rendered=false, por isso os valores internos não mudam (que já estavam "sujos" com o local value antigo, caindo naquela ordem de prioridade do valores: local value antes do model value).

nei.junior wrote:
Rafael,

Entendi sim, porém essa questão do AJAX foi o que pensei por priemiro. Portanto nesse exemplo que criei, não sei se você baixou ai, mas se sim pode observar que eu NÃO utilizo AJAX, é tudo requisição normal para recarregar a página toda e mesmo assim continua errado.
Como não é AJAX ele recarrega toda a página novamente, correto ? Com isso ele deveria reconstruir tudo novamente e vir correto, não é ?

Obrigado por enquanto !

Abraço.

rponte wrote:
Nei,

Eu havia baixado sim seu código. Quando comentei sobre o AJAX foi somente para reforçar, pois normalmente o problema ocorre quando utilizamos muito AJAX. Mas como eu havia dito, seja requisição comum ou AJAX, você continua trabalhando com a mesma árvore de componentes. No seu método editar() você retorna null como regra de navegação, simbolizando para o faces navegar para a mesma página, porém utilizando a mesma árvore de componentes em vez de recriar uma nova árvore.

O problema real está na árvore de componentes "suja". Nas soluções que eu havia dado mais acima eu comentei sobre utilizar a navegação do faces, mas sem retornar null.

rponte wrote:
Na verdade eu gostaria de garantir isso para você, mas já li artigos que afirmam que o local value é setado após a validação e outros dizem que é setado logo após a conversão, na qual a validação só cuidaria de invalidar o componente. Mas no geral, para nós "usuários" do framework que não criamos componentes não faz tanta diferença assim. No mais, o local value também é utilizado para eventos que ocorrem imediatamente após a conversão e validação dentro da própria fase de validação, como por exemplo valueChangeListener's.

danilo.magrini wrote:
O ideal é procurar isso na especificação. Assim que eu tiver um tempo vou vasculhar entre as JSRs 314, 127 e 252 e ver se encontro algo. Porém se fosse para apostar eu apostaria que ele é setado depois da conversão porque pra mim setar o local value depois da validação se tornaria desnecessário uma vez que ele seria setado e logo em seguida receberia null já que o modelo seria atualizado.

nei.junior wrote:Rafael,

Bom concluindo o assunto, entendi. Você deu uma boa clareada neste caso.
Agora vamos ver uma das soluções postada no inicio por você.
O @DaniloMagrini deu uma ideia de propor na lista oficial do Mojarra a criação de algo como:
FacesContext.getCurrentInstance().getViewRoot().invalidate()

O que acha ? Acho que quando cair nessa situação, pelo menos teria uma forma mais simples e objetiva de contornar.

rponte wrote:
Nei,

Antes de mais nada, é importante definir bem o que "invalidar" significa. Significa recriar toda a árvore de componentes? Limpar o estado interno de todos os inputs ou todos os componentes?

O pessoal do Trinidad criou algo semelhante, mas acho que somente para inputs, não me recordo. Tanto que foi incorporado ao JSF 2.x. Se eu pesquisar talvez até ache o artigo.

No mais, eu acredito que você não queira invalidar toda a árvore de componentes, mas sim alguns componentes ou grupo de componentes. Então utilizar navegação é a solução mais simples e o próprio faces já te fornecesse isso.

Enfim, provavelmente há uma forte razão para o ciclo de vida e os componentes trabalharem assim! Se você souber de algo no forum não deixe de me informar.