Você precisa incluir mais de um botão dentro do seu formulário?

Ou então, talvez você já tenha ouvido alguém comentar de ter acontecido algo estranho logo após ter submetido o formulário.

Já ouviu?

Pois eu já ouvi. :)

Uma vez um cliente me mandou uma mensagem dizendo que quando ele ia salvar o registro os dados desapareciam.

Qual você acha que foi minha atitude na época?

Fui fazer testes nesse formulário para inserção do registro e, tudo funcionou direitinho!

“Cliente, fiz os testes aqui e para mim está funcionando perfeitamente“.

Mas ele ainda insistia no erro.

Fiz mais um teste aqui, outro ali, e continuei com a conclusão de que tudo funcionava perfeitamente.

Até que um dia precisei ir até o cliente para resolver um outro assunto.

Claro, ele aproveitou para jogar o erro do formulário na minha cara. :-|

“Olha aqui… Eu faço as alterações, aperto ENTER e limpa tudo!”

Na hora pensei:

“Putz… Ele submete o formulário apertando ENTER“.

O problema é que a ação que o formulário toma ao apertar ENTER é referente ao primeiro botão que está dentro do formulário, e o primeiro botão do formulário na época era LIMPAR.

Nos meus testes eu sempre submetia o formulário com o clique, ao invés de teclar ENTER.

Quem usa mais de um botão no formulário e não conhece o componente DefaultCommand do PrimeFaces, já sabe, meio que no subconsciente, que tem que submeter o formulário com o clique no botão.

No caso que contei para você, eu poderia resolver o problema, simplesmente, alterando a ordem dos botões, mas, considero isso quase uma gambiarra.

Fico no quase porque um formulário foi feito para submeter uma só ação, é o JSF que dá essa ajudinha para incluirmos mais de uma.

Enfim, prefiro usar a solução que vou mostrar pra você agora.

Componente PrimeFaces DefaultCommand

O DefaultCommand serve para configurarmos qual a action padrão de um formulário ao teclarmos ENTER (ou iniciando uma submissão que não seja através do clique no botão).

Veja:

<h:form id="form">
  <p:commandButton id="limparCommandButton" value="Limpar" actionListener="#{contatoBean.limpar}" />

  <p:commandButton id="cancelarCommandButton" value="Cancelar" actionListener="#{contatoBean.cancelar}" />

  <p:commandButton id="salvarCommandButton" value="Salvar" actionListener="#{contatoBean.salvar}" />

  <p:commandButton id="removerCommandButton" value="Remover" actionListener="#{contatoBean.remover}" />

  <p:defaultCommand target="salvarCommandButton" />

  ...
</h:form>

Dessa forma você decide qual será a action padrão de um formulário sem correr o risco de algum outro programador alterar a ordem dos botões.

Você tem algum formulário CRUD?

Chamo de formulário CRUD aqueles que são utilizados ao mesmo tempo para as 4 operações clássicas (criar, ler, atualizar e deletar).

Nesses casos o programador acaba precisando trabalhar com o atributo “rendered” dos botões.

O botão Salvar, por exemplo, precisaria ficar escondido no estado de pesquisa do formulário.

Com isso, para cada estado do formulário (estado de pesquisa, criação e edição), poderíamos ter ações diferentes.

Pensando nesse tipo de situação, podemos usar o atributo rendered para controlar o DefaultCommand por estado:

<h:form id="form">
  ...

  <p:defaultCommand target="pesquisarCommandButton" 
        rendered="#{contatoCrudBean.estadoAtual eq 'PESQUISA'}" />
  <p:defaultCommand target="salvarCommandButton" 
        rendered="#{contatoCrudBean.estadoAtual eq 'INSERCAO' or contatoCrudBean.estadoAtual eq 'EDICAO'}" />

  ...
</h:form>

Ou…

Podemos ter um target variável. Veja:

<h:form id="form">
  ...

  <p:defaultCommand target="#{contatoCrudBean.acaoAtual}" />    

  ...
</h:form>

Repare que quebramos o sentido do nome default command (comando padrão), pois agora temos um comando padrão dinâmico, ou seja, não temos mais um comando padrão.

É… Foi uma observação inútil, eu sei.

Mas, de repente você tem uma outra informação inútil que combinada com essa aqui, vai passar a ter algum valor, vai saber. hehe

Conclusão: DefaultCommand ajudando na criação de formulários com mais de uma ação

A conclusão que cheguei foi que o componente DefaultCommand pode te economizar um bom tempo.

Ele vai evitar que você tenha que parar para ler e-mails ou atender ligações de clientes dizendo, de um jeito difícil de entender, que o formulário está limpando quando deveria salvar.

É isso! :)

E provavelmente, você que chegou até aqui, usa PrimeFaces no seu trabalho, não usa?

Então quero convidá-lo a baixar nosso e-book gratuito sobre Java EE 7 (e, claro, PrimeFaces) que NÃO vai deixar você fazer feio lá no seu meio do seu time:

Depois do download do E-Book sobre Java EE 7 com PrimeFaces você pode também deixar um comentário com o sua opinião, adendo, ressalva, crítica ou elogio.

Um abraço e até uma próxima!

PS: o código-fonte do exemplo desse artigo pode ser acessado em:
http://github.com/algaworks/artigo-jsf-primefaces-defaultcommand