Artigo WebMobile 21 - Desenvolvimento Web com Wicket

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Veja nesse artigo como reduzir e reutilizar o código.

Esse artigo faz parte da revista WebMobile edição 21. Clique aqui para ler todos os artigos desta edição

imagem_pdf.jpg

Web

Desenvolvimento Web com Wicket, Parte 2: Reduzindo e reutilizando código

 

Quando estamos construindo qualquer tipo de aplicação complexa, desejamos reutilizar o máximo de código possível. O problema é, podemos nos sentir impossibilitados de reutilizar código devido a componentes que são apenas um pouco diferentes, mas a ponto de requerer que os construamos do zero. Neste segundo artigo da série, veremos como o Wicket contorna tal problema reduzindo bastante a quantidade de código que você precisa copiar e colar.

Esta série, que começou com o artigo sobre os modos de desenvolvimento do Wicket stateful e stateless, agora parte para a máquina de renderização que é construída neste estado abstrato. O que ela faz para criar componentes customizados, e como eles facilitam o reuso? Para entender isso, iremos usar a aplicação de exemplo da calculadora apresentada no artigo anterior desta série e refatorá-la para eliminar seu código de layout redundante e então avançar para aplicar permutações de calculadoras para um conjunto de páginas da aplicação.

 

Das Páginas para Panels

Uma subclasse WebPage é por si só um componente customizado: se programamos em Wicket, somos autores de componentes em Wicket. Mas as páginas são demasiadamente monolíticas. A forma mais comum de tornar uma porção de uma página reutilizável é movendo esta parte para um panel. Como uma página, um panel do Wicket possui um arquivo de template HTML associado. Ele incorpora pedaços de layout e funcionalidade que podem ser usadas em qualquer página de uma aplicação.

Ao migrar funcionalidade de uma página para um panel, o primeiro passo é criar uma nova subclasse Panel. Como um componente normal (não uma página), a subclasse Panel deve ser inicializada com um identificador de componente; seu construtor de subclasse deve se chamar super() com um ID. Para a aplicação da calculadora, queremos uma classe base com duas subclasses, similar à velha BasePagehierarchy, mas com layout compartilhado. A Listagem 1 exibe a classe panel base.

 

Listagem 1. Panel e Construtor Base para a aplicação da  Calculadora

public abstract class CalcPanel extends Panel {

  public CalcPanel(String id) {

    super(id);

  }

  enum Op { ...

 

                    

O próximo passo é criar a subclasse a partir das duas páginas variantes movendo o código principal para novos panels, mudando apenas os construtores. A Listagem 2 descreve as declarações e construtores das classes.

 

Listagem 2. Subclasses da Calculadora

public class StatelessCalcPanel extends CalcPanel {

  protected BigDecimal buf = BigDecimal.ZERO;

  protected BigDecimal input = BigDecimal.ZERO;

  protected Op op;

 

  public StatelessCalcPanel(String id) {

    super(id);

    add(new CalcForm("form"));

  }

  class CalcForm extends StatelessForm {

    ...

  }

}

 

public class StatelessCalcPanel extends CalcPanel {

  protected BigDecimal buf = BigDecimal.ZERO;

  protected BigDecimal input = BigDecimal.ZERO;

  protected Op op;

 

  public StatelessCalcPanel(String id) {

    super(id);

    add(new CalcForm("form"));

  }

  class CalcForm extends StatelessForm {

    ...

  }

}

                    

Neste ponto, poderíamos fazer ajustes superficiais similares para os templates de marcação e ter dois panels que replicam a funcionalidade das duas páginas originais. Mas em vez disso, neste artigo veremos uma implementação que irá melhorar a funcionalidade original com hierarquia de marcação do Wicket, uma técnica simples para reutilizar layout que provê um ponto de extensão para subclasses.

 

Marcações, faça bom uso deste recurso

O mecanismo de binding para Wicket é flexível com respeito à hierarquia de classe. Uma classe não precisa obrigatoriamente ter um template caso um esteja definido para uma superclasse (classe-mãe). Sem hierarquia de marcação, um template encontrado para uma subclasse substitui o template na superclasse. Com hierarquia de marcação, o template é inserido "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?