Palestra VRaptor 3
•Download as PPTX, PDF•
1 like•299 views
Slides utilizados para uma palestra sobre VRaptor 3, um framework brasileiro criado pela Caleum.
Recommended
More Related Content
Viewers also liked
Viewers also liked (6)
Similar to Palestra VRaptor 3
Similar to Palestra VRaptor 3 (20)
Recently uploaded
Recently uploaded (8)
Palestra VRaptor 3
- 2. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 3. Framework MVC brasileiro Desenvolvido pela Caelum Inspirado no Ruby on Rails Focado no desenvolvimento ágil Diminui drasticamente tempo de trabalho Convenção sobre configuração Roda sobre o Spring
- 4. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 7. Convenção de acesso à view: WEB-INF/jsp/{nomeDoResource}/{nomeDoMétodo}.jsp No nosso caso: WEB-INF/jsp/olaMundo/ola.jsp Como acessaremos a view: localhost:8080/PalestraVRaptor/olaMundo/ola
- 13. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 14. Quais são minhas dependências? Quem instanciará as classes? Como o Vraptor sabe disso?
- 17. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 23. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 24. @RequestScoped (padrão) @SessionScoped @ApplicationScoped @PrototypeScoped
- 25. @PostConstruct: assim que o escopo for iniciado @PreDestroy: assim que o escopo for finalizado
- 27. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 28. Componente Validator do VRaptor Maneira clássica Maneira fluente Integração com o Hibernate Validator Especificar para qual lógica encaminhar
- 35. Validador do VRaptor integrado com o Hibernate Validator
- 39. O que é o VRaptor? Primeiro contato Injeção de dependências Enviando dados via form Escopos definidos Validação REST
- 40. Representation State Tranfer Padrão arquitetural Endereçamento de forma padronizada (nice urls) Maior visibilidade para componentes intermediários Diminui acoplamento entre cliente e servidor
- 42. URI (Unified Resource Identifier) Nome dos recursos Recursos != Ações Má prática: /produto/adiciona
- 43. Conjunto pequeno e fixo de operações Interface uniforme Operações HTTP: › Get, Post, Put, › Delete, Head, Options, Trace
- 44. Get: recuperar dados de um recurso Post: adiciona dados de um recurso Put: adiciona ou modifica dados Delete: deleta o recurso representado na URI Head, Options, Trace: recuperam metadados da URI
- 58. Alta produtividade Curva de aprendizado Testabilidade Economia Flexibilidade Melhores práticas de desenvolvimento
Editor's Notes
- O VRaptor 3 foca em simplicidade e, portanto, todas as funcionalidades que você verá têm como meta resolver o problema do programador da maneira menos intrusiva possível em seu código. Sempre procura encapsular HttpServletRequest, Response, Session e toda a API do javax.servlet. Deixar que o framework cuide da parte web e deixe você focar na linguagem de programação. Os criadores tentaram pegar o melhor de vários frameworks para fazer o próprio.
- O VRaptor trabalha muito com convenções em vez de configurações, portanto, para que nosso sistema funcione, devemos organizar nossos arquivos obedecendo a seguinte convenção: ao criar um controller, suas views devem ficar dentro de uma pasta com o nome idêntico ao do mesmo sendo que com a inicial minúscula. Cada .jsp dentro desta pasta deverá possuir o mesmo nome que os métodos correspondentes em seus respectivos controllers. Cada pasta deve ficar dentro de uma pasta chamada “jsp”
- Repare que a classe não herda de nenhuma outra classe nem implementa nenhuma interface. É um exemplo claro de um POJO. Anotando o controller com @Resource, seus métodos públicos ficarão disponíveis para receber requisições web.
- Ao terminar a execução do método, por convenção, o VRaptor fará o dispatch da requisição para o JSP /WEB-INF/jsp/olaMundo/ola.jsp
- No VRaptor, o retorno do método é exportado para a JSP por meio de atributos da requisição.
- No caso do método lista, vai existir um atributo chamado stringList contendo a lista retornada Se for uma classe qualquer vai ser o nome da classe com a primeira letra minúscula
- O VRaptor está fortemente baseado no conceito de injeção de dependências do Spring, uma vez que chega até mesmo a utilizar dessa ideia para juntar seus componentes internos. Dependência é tudo que um objeto precisa para que seus métodos executem com sucesso. O conceito básico de DI (Dependency Injection) é que tudo que um objeto depende deve ser entregue a ele, em vez de ele ter que ir atrás de cada uma de suas dependências. Pra isso, anotamos com @Component todas as classes que são dependência de alguma outra. Então o VRaptor se encarregará de instanciar as classes e injetar as dependências quando ele ver que determinada classe pede um certo objeto em seu construtor.
- Nesse caso, Result é uma classe interna do próprio VRaptor que já está configurada como dependência. Já ProdutoDao foi anotada como dependência por nós.
- Geralmente em outros framekworks, quando termina uma ação a gente manda para a aplicação ir para uma determinada URI. Mas se essa URI mudar um dia quebra toda tua aplicação. Em vez de, por exemplo, ir num arquivo de configuração (que é uma terceirização), a gente faz isso a nível de código no próprio controller. Isso favorece o refactor, pois por exemplo, se eu refatorar meu método, eu reflito isso nos meus redirecionamentos. O redirect acontece no lado do cliente, através de códigos HTTP que farão o browser acessar uma nova URL; Já o forward acontece no lado do servidor, totalmente transparente para o cliente/browser. Um bom exemplo de uso do redirect é no chamado 'redirect-after-post'. Por exemplo: quando você adiciona um cliente e que, após o formulário submetido, o cliente seja retornado para a página de listagem de clientes. Fazendo isso com redirect, impedimos que o usuário atualize a página (F5) e reenvie toda a requisição, acarretando em dados duplicados. No caso do forward, um exemplo de uso é quando você possui uma validação e essa validação falhou, geralmente você quer que o usuário continue na mesma tela do formulário com os dados da requisição preenchidos, mas internamente você vai fazer o forward para outra lógica de negócios (a que prepara os dados necessários para o formulário).
- @Request: o componente será criado sempre a cada requisição @Session: o compoenente será criado um vez por sessão @Application: o componente será criado uma única vez em todo o tempo de vida da aplicação @Prototype: o componente será criado sempre que for solicitado
- VRaptor permite anotações bem uteis do Java EE 5, as quais devem ser utilizadas em métodos Dessa forma podemos usar o @PostConstruct para criação da fábrica de sessões E usar o @PreDestroy pra fechar a nossa fábrica
- Maneira clássica: você faz os if’s e coloca as mensagens manualmente; Maneira fluente: você diz o que quer que seja verdade, e caso não seja, adiciona uma mensagem internacionalizada (tem colocar as chaves no seu arquivo message.properties); Em ambas as maneiras é preciso indicar para onde voltar quando ocorrer algum erro. No nosso caso, queremos voltar para o formulário.
- No estilo fluente, estabelecemos a regra. Se não for obedecida, estouramos o erro A ideia é que o código para fazer a validação seja algo muito parecido com a linguagem natural
- No estilo fluente, a ideia é que o código para fazer a validação seja algo muito parecido com a linguagem natural
- REST é um conjunto de restrições que define um padrão arquitetural com características específicas. Permite o endereçamento dos recursos de forma padronizada.
- Requisição HTTP tem três tipos de componentes importantes. Uma aplicação RESTful costuma reforçar mais ss sbustantivos do que os verbos. A vantagem de seguir isso é que conseguimos aproveitar toda a estrutura que o protocolo HTTP proporciona
- Quando fazemos requisições web nós precisamos falar o caminho da mesma, a URI, ou seja, o identificador de um recurso. Para representar a adição de um produto por exemplo, podemos usar a URI /produto aliado ao método Post do HTTP, o qual representa adição de dados.
- Uma boa e importante prática do REST é que você tenha uma conjunto pequeno e fixo de operações bem definidas, gerando assim uma interface uniforme. É interessante que duas aplicações diferentes conversem entre si sem implementar várias operações diferentes. Perceba que adicionar um produto é basicamente a mesma ação que adicionar um usuário. Padronize isto!
- Put != Post, pois no Post a URI indica o local onde será tratada a informação, já no Put indica o local será armazenada a informação. Head: recupera o Header Options: recupera quais métodos são possíveis Trace: informações de debug. Quando fazemos uma aplicação, não trafegamos um recurso pela rede, mas sim a representação dele.
- Cada verbo HTTP tem uma semântica diferente, se uma operação não segue a semântica dos verbos, não se deve aceitar o mesmo. Exemplo: o método “listaTudo()” é uma operação idempotente, ou seja, pode ser chamada quantas vezes quiser que não vai haver nenhum efeito colateral, e se o banco não mudou, vai ter sempre o mesmo resultado. Logo, faz sentido que o verbo HTTP para acessar esse método seja o Get. A partir do momento que colocamos uma anotação de verbo HTTP no nosso método, ele não pode mais ser acessado pelos outros verbos. Se tentarmos fazer uma requisição Post pra “/produto”, a requisição vai retornar um status 405 (Método não suportado), que quer dizer que existe um recurso nessa URI, mas que não suporta o verbo HTTP Post.
- Mas podemos colocar mais um método que responda à mesma URI, desde que os verbos HTTP sejam diferentes. Nesse nosso caso, fazemos com que o método “add()” seja atendido pela mesma URI “/produto” do método “listaTudo()” porém, usando o verbo HTTP Post. E como esta operação não é idempotente, se eu repetir duas vezes uma requisição, vou estar adicionando dois produtos, não sabemos qual vai ser a URI dele, por isso cabe perfeitamente usar o verbo Post.
- No momento de criar os links e formulários HTML devemos tomar um cuidado muito importante pois os browsers só dão suporte aos métodos POST e GET por meio de formulários hoje em dia. Por isso, você deverá criar as requisições para métodos do tipo DELETE, PUT etc usando JavaScript ou passando um parâmetro extra, chamado _method. O último só funciona em requisições POST. Esse parâmetro sobrescreverá o método HTTP real sendo invocado.
- No momento de criar os links e formulários HTML devemos tomar um cuidado muito importante pois os browsers só dão suporte aos métodos POST e GET por meio de formulários hoje em dia. Por isso, você deverá criar as requisições para métodos do tipo DELETE, PUT etc usando JavaScript ou passando um parâmetro extra, chamado _method. O último só funciona em requisições POST. Esse parâmetro sobrescreverá o método HTTP real sendo invocado.
- No momento de criar os links e formulários HTML devemos tomar um cuidado muito importante pois os browsers só dão suporte aos métodos POST e GET por meio de formulários hoje em dia. Por isso, você deverá criar as requisições para métodos do tipo DELETE, PUT etc usando JavaScript ou passando um parâmetro extra, chamado _method. O último só funciona em requisições POST. Esse parâmetro sobrescreverá o método HTTP real sendo invocado.
- ALTA PRODUTIVIDADEa Usar o VRaptor 3 é simples e intuitivo. Você atingirá níveis altíssimos de produtividade com Java para Web. CURVA DE APRENDIZADO Em pouco tempo você conseguirá aprender tudo o que é necessário para desenvolver suas aplicações com o VRaptor. TESTABILIDADE Escreva código modularizado e desacoplado do VRaptor. Sua aplicação fica altamente testável e de fácil manutenção. ECONOMIA Economize muitas horas de trabalho com a alta produtividade do VRaptor, a facilidade em treinar a sua equipe e a qualidade final do seu projeto. FLEXIBILIDADE Integre o seu projeto com qualquer framework de sua preferência. Você não estará preso a nenhuma tecnologia específica. MELHORES PRÁTICAS DE DESENVOLVIMENTO Utilizando os conceitos de Injeção de Dependência, Inversão de Controle e POJOs, seu código fica simples e testável.