Curso JSF

fevereiro 6, 2008 às 3:16 pm | Publicado em Java, JEE | Deixe um comentário

globalcode.jpg

Todos sabem que gosto de estudar novas tecnologias, conhecer suas vantagens e desvantagens.

Agora em fevereiro fui escolhido na minha equipe para fazer um curso de JSF na Globalcode. Vai ser legal, pois irei tirar algumas dúvidas que surgiram durante algumas semanas de estudo sobre JSF.

Serão abordados alguns tópicos interessantes como criação de componentes e renderizadores personalizados e como adicionar suporte a ajax em aplicações JSF.

Em breve vocês irão ler alguns tópicos sobre Java Server Faces aqui no blog.

Abraços e feliz 2008!!!

Arquitetura e Design de Projetos Java

setembro 28, 2007 às 11:26 pm | Publicado em Desenvolvimento, Java, JEE, Outros | 4 Comentários

Caelum - Arquitetura de projetos Java

Amanhã começa o curso de Arquitetua e Design de Projetos Java na caelum. Não resisti e me matriculei.

Sempre me interessei por arquitetura de sistemas e achei um ótima oportunidade para melhorar meus conhecimentos. Atualmente considero os cursos da Caelum os melhores do Brasil.

No curso serão abordados temas que sempre me interessei mas nunca tive tempo para estudar. Dentre eles dou destaque para: Domain Driven Design, Instrumentação e Manipulação de bytecode, Freemarker, Lucene e SOA.

Você poderá acompanhar aqui no blog alguns artigos sobre os temas discutidos no curso.

Quem quiser dar uma melhorada no conhecimento, aconselho dar uma olhada nos cursos que a Caelum oferece.

t+

Minha Opinião sobre a JPA

junho 29, 2007 às 12:01 am | Publicado em Java, JEE | 2 Comentários

A java persistence API ou simplesmente JPA foi lançada como uma das grandes novidades do Java EE 5. A idéia de criar uma especificação para frameworks ORM é bem interessante e foi muito bem aceita por toda a comunidade.

Mas nem tudo é maravilha. Eu esperava muito mais da API e hoje a considero como um subconjunto do hibernate. Muitas funcionalidades interessantes que o hibernate oferece não fazem parte da especificação, como a API de Criteria.

Quem já usa o hibernate não vai estranhar a mudança para a JPA. Como o hibernate já permitia que a classes fossem mapeadas com as anotações do JPA, a mudança fica em alterar as interfaces utilizadas, como exemplo Session por EntityManager.

Pra falar que não achei nada de interessante na JPA, os nomes dos métodos ficaram mais interessantes. Basta olhar para um entityManager.find(xx) ou entityManager.persist(xx) para saber o que ele faz. 🙂

Acho que a grande prova de que a API está incompleta e imatura é o fato de permitir acessar o provider utilizado. O provider deveria ser abstraído e sempre ser utilizado através das interfaces do JPA.

Se você é preguiçoso como eu e não gosta de escrever HQL ou JPAQL, pode fazer isso:

jpa_1.jpg

É isso mesmo que você está vendo, chamando o método getDelegate() é possível recuperar o provider que está sendo utilizado, como exemplo uma Session do hibernate e executar uma criteria. Parece interessante mais isso é muito perigoso e quebra umas dos princípios da JPA, a independência de um provider.

Resumindo, vou continuar com o Hibernate em meus projetos e esperar a versão 2.0 da JPA, onde está sendo prometido uma API parecida com a Criteria além de outras anotações bem interessantes que hoje só existe no Hibernate.

E você, o que achou da JPA???

Vantagens do VRaptor

maio 12, 2007 às 11:39 am | Publicado em Java, JEE | 14 Comentários

Assim como o struts e companhia, o VRaptor é um controlador MVC para web, ou seja, mais um framework para auxiliar o desenvolvedor a usar MVC em suas aplicações. Mas o que faz com que o VRaptor venha conquistando tantos usuários? Vou relatar algumas características interessantes e que fez com que eu escolhesse o VRaptor como o meu controlador MVC preferido.

Rápido aprendizado

Você não precisa se preocupar com treinamento da equipe. É muito simples trabalhar com o VRaptor. Posso garantir que 2 dias é o suficiente pra conhecer todo seu funcionamento.

Nada de HttpServletRequest, HttpServletResponse e HttpSession

O VRaptor tira do desenvolvedor a responsabilidade de trabalhar diretamente com as classes da API dos Servlets através de simples anotações.
Suponha que existe uma Action (que no VRaptor é Logic) que precisa passar um objeto Pessoa para ser mostrado em uma jsp.

Classe Exemplo

– para inserir o objeto como um atributo na requisição basta a anotação @Out:

@Out
private Pessoa pessoa = new Pessoa();

– para inserir o objeto na sessão basta mudar o escopo na anotação @Out:

@Out(scope=ScopeType.SESSION)
private Pessoa pessoa = new Pessoa();

Da mesma forma existe a anotação @In para recuperar atributos dos escopos (requisição, sessão, aplicação e logic???).

Logic é um novo escopo para seus objetos. Um objeto neste escopo ficará disponível durante a lógica de negócios, ou seja, quando a requisição for direcionada para a JSP o objeto não estará mais acessível. Já precisei deste escopo usando o struts e adivinhem? com certeza tive que implementar tudo…rs

Pouquíssima configuração

O VRaptor trabalha por convenções o que diminui relativamente o número de configurações. Por exemplo, marcando uma classe com a anotação @Component, automaticamente todos os métodos públicos estarão disponíveis para serem acessados pela view.

A convenção também é aplicada nos redirecionamentos após a execução de um método na Action (Logic). Veja no exemplo acima, que o método não retorna nenhuma string ou objeto indicando para qual recurso a requisição deverá ser direcionada. O VRaptor irá direcionar para uma jsp com o padrão ‘/nomeComponente/nomeMetodo.ok.jsp’.

Vale ressaltar que se for necessário é possível customizar o funcionamento de uma forma bem simples.

A não existência de taglibs

Na minha opinião, um controlador mvc não deveria interferir na view. Sua responsabilidade é apenas controlar as requisições, direcionando-as para as classes responsáveis por tratá-las. Encher sua JSP com taglibs de frameworks MVC é muito perigoso e arriscado. Use um padrão (JSTL) e caso seja necessário crie as suas próprias.

O VRaptor não possui um pacote de taglib. Use expression language + JSTL e seja feliz….

———————-

Em breve colocarei mais exemplos e características do VRaptor. Espero convencer a todos a pelo menos baixar e testar este incrível framework.

${EL.parte2}

fevereiro 10, 2007 às 12:55 pm | Publicado em JEE | 2 Comentários

Continuando o post sobre a Expression Language, devemos prestar atenção em outro detalhe importante: objetos implícitos.

Os objetos implícitos da EL, assim como os da JSP, facilitam o acesso às propriedades ou métodos de objetos que podem estar em diferentes escopos da aplicação.

  • param e paramValues: Map com os parâmetros da requisição.
  • header e headerValues: Map com os cabeçalhos da requisição.
  • cookie: Map com os cookies da requisição.
  • initParam: Map com os parâmetros init do contexto.
  • pageScope, requestScope, sessionScope, applicationScope: Map com os atributos dos escopos.

Exemplos de uso dos objetos implícitos:

${param.nome}

${paramValues.cidades[1]}

${header.host} ou ${header[“host”]} – vimos a diferença na primeira parte do tutorial

${requestScope.pessoa.nome} – recupera o nome do objeto pessoa que está na requisição

E se você quiser obter o método utilizado na requisição HTTP (GET, POST, etc…). Precisamos invocar o método getMethod() do objeto request . Então podemos utilizar o objeto implícito requestScope para recuperar o método.

${requestScope.method}

Ops… Porque não funcionou? Lembre-se que requestScope é um map com os atributos da requisição. É apenas um Map com os atributos… Você não tem acesso às propriedades da requisição.

Eis que surge o objeto implícito pageContext. Este é o único objeto implícito que não é um Map. Através do pageContext podemos recuperar o objeto request:

${pageContext.request.method}

Outro ponto importante é a ordem em que o container procura por atributos nos diferentes escopos. Caso você não informe um escopo, a ordem será pageScope, requestScope, sessionScope e applicationScope.

ex:

em um servlet:

request.setAttribute(“nome”, “marcelo”);

session.setAttribute(“nome”, “maria”);

na jsp:

${requestScope.nome} – Marcelo //o atributo da requisição

${sessionScope.nome} -Maria // o atributo da sessão

${nome} – Marcelo // o atributo da requisição?

Se você não informar o escopo, o container primeiro procura pelo atributo “nome” no pageScope, se não encontrar nada, ele busca no requestScope. No exemplo, ele encontrou a propriedade no requestScope, então ele para a busca pelo atributo e imprime o atributo da requisição. Portanto, em alguns casos pode ser muito útil informar o escopo do atributo.

Comentem….

Próxima Página »

Blog no WordPress.com.
Entries e comentários feeds.