Introdução ao vRaptor
vRaptor - motivação
Pontos fortes:
● Framework brasileiro;
● Documentação em português;
● Aprendizagem fácil;
● Convenções ao invés de XML;
● Mais liberdade;
● Facilita muito o trabalho de web designers.
Pontos fracos:
● Maior conhecimento em HTML/CSS/Javascript;
vRaptor - convenções
● Arquivos JSP devem estar sempre em /WEB-INF/jsp.
● Classes controladoras devem ter seu nome
terminando com “Controller”, e anotadas com
@Resource.
vRaptor - convenções
Cuidado:
● Não existe problema em ter Controllers em outros
pacotes, desde que não existam classes com o mesmo
nome.
vRaptor - convenções
● Arquivos JSP referentes a determinado controlador
devem estar em uma pasta com o seu nome(estilo
lowerCamelCase, e excluindo a palavra “Controller”), dentro
de /WEB-INF/jsp .
vRaptor - convenções
● O nome do arquivo JSP precisa ser igual ao nome do
método no controlador.
● A URL de acesso fica no formato
domínio/contexto/controlador/método
● No caso acima:
localhost:8080/minhaApp/produto/novo
vRaptor - convenções
● Métodos podem retornar objetos, que ficam
disponibilizados na JSP através da EL. O nome do
parâmetro é gerado conforme o tipo de retorno.
→ public String retorno(){...} = ${string}
→ public Integer retorno(){...} = ${integer}
→ public Produto visualiza(){...} = ${produto}
→ public List<Produto> retorno(){...} = ${produtoList}
vRaptor - convenções
● Podemos alterar a URI padrão gerada para
determinado método com a anotação @Path.
Agora, a URI fica /produto/novo e não mais /produto/adiciona
● Nos controladores, métodos públicos e sem nenhuma
anotação são considerados métodos Get (mesmo sentido
do doGet no Servlet).
vRaptor - convenções
● Quando queremos que determinado método trate de
um Post, devemos anotá-lo com @Post .
● Podemos receber parâmetros em nossos métodos de
lógica. Mas...como?
vRaptor - convenções
● Podemos receber parâmetros via URL e injetá-los nos
objetos recebidos no método.
→ Ao chamar /clientes/9 , o objeto cliente terá o
atributo id setado com o valor 9.
vRaptor - prática
● Criar um projeto com vRaptor, baseado no projeto
em branco disponibilizado, testando as principais
funcionalidades.
Pode ser utilizado o exemplo da calculadora.
vRaptor – um pouco de IoC
● Antes de prosseguir, vamos ver um pouco sobre
Inversão de Controle e Injeção de Dependências.
● No vRaptor, as dependências necessárias podem ser
recebidas no construtor do controlador.
● Mas o que é Inversão de Controle e Injeção de
Dependências?
Inversão de Controle
● A Inversão de Controle é um padrão de
desenvolvimento onde se inverte o fluxo normal de
programação, delegando a responsabilidade sobre
algumas partes do código para alguns frameworks ao
invés de criarmos toda a sequência.
● Supomos um exemplo:
→ Temos um controlador que salva produtos. Para salvar
produtos precisamos de um ProdutoDao. Normalmente
faríamos no construtor do controlador algo como
this.produtoDao = new ProdutoDao();
Mas, e se um dia ProdutoDao necessitar de algum parâmetro
no seu construtor? Teremos de alterar o código do controlador.
Qual é o problema?
Inversão de Controle
● O problema é que o controlador sabe demais. Foi
delegada a ele a responsabilidade de criar um
ProdutoDao, gerando um acoplamento muito grande
entre as duas classes.
● Não seria melhor deixar que algum framework crie
um ProdutoDao e somente recebermos uma instância
para chamar seus métodos?
● Isso é Injeção de Dependências!!
Inversão de Controle
● ProdutoController depende de um ProdutoDao, mas
não é sua responsabilidade criá-lo. Então, um
framework externo cria ProdutoDao e injeta em
ProdutoController.
● Você não deve buscar aquilo que deseja acessar, mas
tudo o que deseja acessar deve ser fornecido para
você.
● Só pra lembrar: Inversão de Controle é um padrão
de desenvolvimento, e Injeção de Dependências é
uma maneira de resolver/implementar a Inversão de
Controle.
Voltando ao vRaptor – o objeto Result
● O vRaptor disponibiliza um objeto para trabalhar com
alguns recursos relacionados à View, como por
exemplo redirecionar, serializar objetos e adicionar
parâmetros para a JSP.
● Este objeto, chamado Result, pode ser injetado nos
controladores através do construtor.
vRaptor – o objeto Result
● O Result pode redirecionar o fluxo para outra lógica
de outro controlador.
● O Result pode modificar a view padrão, retornando
JSON, XML, Status HTTP ao invés de JSP.
vRaptor – o objeto Result
● O Result pode adicionar objetos no request,
tornando-os acessíveis na JSP.
● O Result pode redirecionar o fluxo caso ocorra uma
Exception.

Introdução ao vraptor

  • 1.
  • 2.
    vRaptor - motivação Pontosfortes: ● Framework brasileiro; ● Documentação em português; ● Aprendizagem fácil; ● Convenções ao invés de XML; ● Mais liberdade; ● Facilita muito o trabalho de web designers. Pontos fracos: ● Maior conhecimento em HTML/CSS/Javascript;
  • 3.
    vRaptor - convenções ●Arquivos JSP devem estar sempre em /WEB-INF/jsp. ● Classes controladoras devem ter seu nome terminando com “Controller”, e anotadas com @Resource.
  • 4.
    vRaptor - convenções Cuidado: ●Não existe problema em ter Controllers em outros pacotes, desde que não existam classes com o mesmo nome.
  • 5.
    vRaptor - convenções ●Arquivos JSP referentes a determinado controlador devem estar em uma pasta com o seu nome(estilo lowerCamelCase, e excluindo a palavra “Controller”), dentro de /WEB-INF/jsp .
  • 6.
    vRaptor - convenções ●O nome do arquivo JSP precisa ser igual ao nome do método no controlador. ● A URL de acesso fica no formato domínio/contexto/controlador/método ● No caso acima: localhost:8080/minhaApp/produto/novo
  • 7.
    vRaptor - convenções ●Métodos podem retornar objetos, que ficam disponibilizados na JSP através da EL. O nome do parâmetro é gerado conforme o tipo de retorno. → public String retorno(){...} = ${string} → public Integer retorno(){...} = ${integer} → public Produto visualiza(){...} = ${produto} → public List<Produto> retorno(){...} = ${produtoList}
  • 8.
    vRaptor - convenções ●Podemos alterar a URI padrão gerada para determinado método com a anotação @Path. Agora, a URI fica /produto/novo e não mais /produto/adiciona ● Nos controladores, métodos públicos e sem nenhuma anotação são considerados métodos Get (mesmo sentido do doGet no Servlet).
  • 9.
    vRaptor - convenções ●Quando queremos que determinado método trate de um Post, devemos anotá-lo com @Post . ● Podemos receber parâmetros em nossos métodos de lógica. Mas...como?
  • 10.
    vRaptor - convenções ●Podemos receber parâmetros via URL e injetá-los nos objetos recebidos no método. → Ao chamar /clientes/9 , o objeto cliente terá o atributo id setado com o valor 9.
  • 11.
    vRaptor - prática ●Criar um projeto com vRaptor, baseado no projeto em branco disponibilizado, testando as principais funcionalidades. Pode ser utilizado o exemplo da calculadora.
  • 12.
    vRaptor – umpouco de IoC ● Antes de prosseguir, vamos ver um pouco sobre Inversão de Controle e Injeção de Dependências. ● No vRaptor, as dependências necessárias podem ser recebidas no construtor do controlador. ● Mas o que é Inversão de Controle e Injeção de Dependências?
  • 13.
    Inversão de Controle ●A Inversão de Controle é um padrão de desenvolvimento onde se inverte o fluxo normal de programação, delegando a responsabilidade sobre algumas partes do código para alguns frameworks ao invés de criarmos toda a sequência. ● Supomos um exemplo: → Temos um controlador que salva produtos. Para salvar produtos precisamos de um ProdutoDao. Normalmente faríamos no construtor do controlador algo como this.produtoDao = new ProdutoDao(); Mas, e se um dia ProdutoDao necessitar de algum parâmetro no seu construtor? Teremos de alterar o código do controlador. Qual é o problema?
  • 14.
    Inversão de Controle ●O problema é que o controlador sabe demais. Foi delegada a ele a responsabilidade de criar um ProdutoDao, gerando um acoplamento muito grande entre as duas classes. ● Não seria melhor deixar que algum framework crie um ProdutoDao e somente recebermos uma instância para chamar seus métodos? ● Isso é Injeção de Dependências!!
  • 15.
    Inversão de Controle ●ProdutoController depende de um ProdutoDao, mas não é sua responsabilidade criá-lo. Então, um framework externo cria ProdutoDao e injeta em ProdutoController. ● Você não deve buscar aquilo que deseja acessar, mas tudo o que deseja acessar deve ser fornecido para você. ● Só pra lembrar: Inversão de Controle é um padrão de desenvolvimento, e Injeção de Dependências é uma maneira de resolver/implementar a Inversão de Controle.
  • 16.
    Voltando ao vRaptor– o objeto Result ● O vRaptor disponibiliza um objeto para trabalhar com alguns recursos relacionados à View, como por exemplo redirecionar, serializar objetos e adicionar parâmetros para a JSP. ● Este objeto, chamado Result, pode ser injetado nos controladores através do construtor.
  • 17.
    vRaptor – oobjeto Result ● O Result pode redirecionar o fluxo para outra lógica de outro controlador. ● O Result pode modificar a view padrão, retornando JSON, XML, Status HTTP ao invés de JSP.
  • 18.
    vRaptor – oobjeto Result ● O Result pode adicionar objetos no request, tornando-os acessíveis na JSP. ● O Result pode redirecionar o fluxo caso ocorra uma Exception.