Este é o primeiro de uma série de artigos para mostrar o Wicket à comunidade brasileira. Cada artigo que eu ler sobre JSF, Facelets e afins que achar interessante e me questionar: "seria ainda mais divertido fazer isso com Wicket", vou fazer um "fork" do artigo e codificá-lo com o Apache Wicket.

Para começar, vou forkar o artigo do Eder Magalhães sobre como tornar um trecho de código Facelets em um componente reutilizável, chamado "Facelets ainda mais divertido! Parte II".

[início do fork]
Neste post vou comentar sobre a criação de componentes usando somente HTML simples e Java puro - na minha opinião o grande diferencial do Wicket. O cenário é um formulário de manutenção de registros de funcionários, e o protótipo é simples:


É comum um protótipo ser entregue por Web Designers, e o nosso trabalho está em adaptar aquele protótipo para processar informações dinâmicas. A página acima se chama CadastroFuncionarios.html e a seguir, o código que o Web Designer entregou:

CadastroFuncionarios.html

Mas é comum ter trechos de telas que são repetitivos. Como os botões de ações deste formulário. Então é interessante tornar isso um componente para ser reutilizado e quando exigir modificação, que seja apenas uma vez, em um único lugar.

No Wicket, páginas são componentes, e funcionam em pares (Java e HTML). Como queremos construir um componente com os botões, precisamos de um painel, para ser reutilizado em outras páginas. O primeiro passo é criar a classe e um HTML exclusivo para o painel, contendo somente os componentes de botão.

Para criar um novo painel para agrupar componentes, existe a classe Panel. Vamos criar uma subclasse dela e especializá-la:

BarraBotoes.java

Por se tratar de um painel de botões, deixei implementado 3 métodos associados 1 para cada botão. Quem utilizar este componente, poderá facilmente sobrescrever estes métodos para adicionar funcionalidades por ação. Outra vantagem aqui está na documentação gerada automaticamente, se o programador preencher o Javadoc.

Para finalizar o componente (segunda etapa), é preciso o HTML do painel, chamado de BarraBotoes.html

BarraBotoes.java

A tag wicket:panel é uma das poucas tags especiais (carregadas pelo DTD). Aqui ela serve para delimitar o que representa o painel, sem prejudicar as ferramentas WYSIWYG. Deixei propositalmente o restante do código HTML por fora da tag para representar um protótipo, que pode ser visto pelo designer e ajustado por ele próprio, caso queira mudar folhas de estilo. A vantagem é que ele pode avaliar se estas mudanças atenderão os requisitos de design. Ou seja, o protótipo continua funcional. Também foi feito o binding entre os componentes no HTML e os componentes em Java através do atributo wicket:id.

A partir desse momento, o painel pode ser reutilizado. Nenhuma outra configuração é necessária. Exceto um import da classe em outras páginas. :-)

Agora precisamos ajustar a página que conterá o painel. Abaixo, o novo HTML da página CadastroFornecedores.html já com os ajustes para binding com Wicket:

CadastroFuncionarios.html

E o código Java para a página:

CadastroFuncionarios.java

Para implementar uma ação, o programador precisa somente sobrescrever os métodos que lhe for necessário. Agora que a página está pronta, e utilizando o componente, o próximo passo é melhorar a inteligência do componente, com zero de alterações nos HTMLs, poucos ajustes na classe do painel BarraBotoes, e uma linha de alteração na classe da página.



  • Apresentar o botão excluir de forma condicional, com base em um boolean
  • Botão cancelar deve sempre abortar o formulário onde estiver contido
Caso seja de interesse do programador acrescentar mais lógica no componente, para que por exemplo os botões tenham visibilidade condicional, ajustes na classe BarraBotoes devem ser feitos. E somente nela. No HTML nada precisa ser alterado. Abaixo, o código da classe com lógica de visibilidade condicional de botões:

BarraBotoes.java

A primeira acao foi adicionar um construtor que recebesse um Model (assunto para outro post), do tipo Boolean, e associar este Model como condicional para o método isVisible() do botão excluir.

A segunda ação foi ajeitar o construtor padrão para continuar funcionando como anteriormente, e mantendo assim compatibilidade com páginas que sempre mostram o botão excluir. Novas páginas poderão utilizar o novo construtor e condicionar a exibição do botão, se quiserem.

A terceira ação foi cancelar o processamento dos dados do form quando o botão cancelar for clicado. Para isto, a propriedade defaultFormProcessing deve ser desabilitada.
[fim do fork]

A grande vantagem do Wicket está em jogar para o lado Java toda a programação da interface, deixando o protótipo limpo, estático, e mesmo assim permitindo o programador manipular com uso inteligente da orientação a objetos, os componentes de tela.

O que mais você gostaria de saber sobre o Wicket?

Abraço,
Bruno

PS: mock de tela feito no Mockflow

** Nota do autor **
Este post foi originalmente publicado no B3.