fev 27 2010

Spring MVC 3.0 na prática – Parte 1

Category: Spring MVC 3.0Edson Gonçalves @ 2:50

Olá, tudo bom? Como vão vocês?
Este artigo é o primeiro de uma série ao qual vou ensiná-los a trabalhar com o Spring MVC 3.0.
Nesta primeira parte iremos conhecer o framework Spring MVC 3.0 através de um simples exemplo no estilo “Hello World!”.
Dúvidas e críticas são bem vindas.

Iniciando com o Spring MVC 3.0

Embora no Brasil o mais famoso do Spring Framework seja sua implementação tradicional como contêiner IoC (Inversion of Control – Inversão de Controle[¹]), também temos um excelente framework Web chamado de Spring MVC.

O Spring MVC é um framework open-source que usa como princípio o design MVC  Model 2, ao qual possui suporte, em sua view, também para outras tecnologias como: JSP/JSTL/Tiles, XML/XSLT, Velocity e  FreeMarker. A integração com JasperReports e exportação de documentos para PDF e Excel também estão inclusas.

Em Spring MVC 3.0 – Parte 1, iremos aprender a configurar um ambiente e rodar um exemplo simples utilizando o Spring MVC 3.0.

Download do Framework

Para trabalhar com o Spring MVC 3.0, você deve realizar o download na página: http://www.springsource.org/download. No momento em que este artigo é escrito, a versão utilizada é a Spring Framework 3.0.1.RELEASE. Clique em Download. Neste framework, temos mais de uma opção para baixar. Vamos escolher apenas o framework, cujo tamanho é o menor de todos.

Download do Spring Framework em sua página oficial

Figura 1 - Download do Spring Framework em sua página oficial

Ao baixar, descompacte o arquivo extraindo todos os JARs existentes no diretório lib.

O ambiente de trabalho

A própria empresa responsável pelo Spring Source, divisão da VMware, possui uma ferramenta completa, criada sobre a plataforma Eclipse, chamada de SpringSource Tools Suite.

Para baixar o SpringSource Tools Suite, clique aqui, preencha o formulário e faça o Download. Como a ferramenta possui uma opção de instalador, use-a como facilitador se desejar. Na própria página onde baixar o arquivo, haverá a explicação da instalação em cada plataforma, em Installation Instructions.

Criando um projeto

No SpringSource Tools Suite, clique no menu File>New>Dynamic Web Project. Na caixa de diálogo New Dynamic Web Project, digite ConhecendoSpringMVC (ou o nome que desejar dar) em Project name.

O SpringSource Tools Suite possui embutido um servidor de aplicações Java Web baseado no Apache Tomcat 6, só que com algumas modificações. Como já o temos por padrão, ele será utilizado no primeiro projeto de exemplo.  Confirme no botão Finish.

Criando o projeto ConhecendoSpringMVC

Figura 2 - Criando o projeto Conhecendo SpringMVC

O Apache Tomcat no Projeto

Caso deseje configurar o Apache Tomcat 6.0.x, pode ser adicionado através do botão New. Siga os passos a seguir para instalar:

1) Expanda Apache e selecione Apache Tomcat v6.0. Clique em Next;

Selecionando o Apache Tomcat v6.0 para adicionar a ferramenta

Figura 3 - Selecionando o Apache Tomcat v6.0 para adicionar a ferramenta

2) Na etapa seguinte, em Tomcat Server, selecione Download and Install;

Baixando e Instalando o servidor Apache Tomcat

Figura 4 - Baixando e Instalando o servidor Apache Tomcat

3) Antes de baixar, aceite os termos de licença. Confirme no botão Finish.

Termos de licença para a instalação automática do Tomcat

Figura 5 - Termos de licença para a instalação automática do Tomcat no SO Windows 7

Determine o local onde será instalado o Apache Tomcat e confirme. Retornando a etapa onde determinamos o local de instalação do Tomcat, se houver erro de não reconhecimento após baixá-lo (veja a execução do download na barra de status da ferramenta), clique em Browse e OK novamente para que seja reconhecido o local de instalação. Por fim, confirme em Finish.

Finalizando o projeto

Após retornar a etapa final do projeto, confirme no botão Finish. O SpringSource Tools Suite pedirá para que você mude de perspectiva. E confirme.

Associando a perspectiva ao tipo de projeto a ser criado

Figura 6 - Associando a perspectiva ao tipo de projeto a ser criado

Ao finalizar o assistente, terá um projeto criado e acessível através da view Project Explorer.

Projeto com sua estrutura gerada

Figura 7 - Projeto com sua estrutura gerada

Adicionando as bibliotecas ao projeto

Clique com o direito sobre o projeto, na view Project Explorer e selecione, no menu de contexto, o item Properties.

Na caixa de diálogo aberta, vá até Java EE Module Dependencies e adicione os seguintes JARs do Spring Framework que descompactou (através do botão Add JARs):

org.springframework.asm-3.0.1.RELEASE-A.jar
org.springframework.beans-3.0.1.RELEASE-A.jar
org.springframework.context.support-3.0.1.RELEASE-A.jar
org.springframework.context-3.0.1.RELEASE-A.jar
org.springframework.core-3.0.1.RELEASE-A.jar
org.springframework.expression-3.0.1.RELEASE-A.jar
org.springframework.web.servlet-3.0.1.RELEASE-A.jar
org.springframework.web-3.0.1.RELEASE-A.jar

Após adicionar estes JARs, clique em OK para confirmar.

Bibliotecas do Spring Framework adicionadas ao projeto

Figura 8 - Bibliotecas do Spring Framework adicionadas ao projeto

Seu primeiro projeto Spring MVC 3.0

O projeto deste artigo como início será o famoso “Hello World”, necessário para compreendermos as configurações básicas do framework.

Configurando o web.xml

Dê um duplo clique em  Deployment Descriptor na view Project Explorer e altere o arquivo conforme é exibido na Listagem 1:

Listagem 1 – Configurações do Spring Framework no web.xml

Para que o Spring funcione, incluindo o seu módulo MVC, utilizamos o servlet org.springframework.web.servlet.DispatcherServlet, configurado no arquivo web.xml da aplicação.

Por padrão, o Spring MVC procura por beans em arquivos de configuração do próprio framework cujo o princípio de nome possui um similar ao do Servlet configurado no web.xml, seguido de -servlet.xml. A Listagem 2 coloca em prática esta situação, criando o arquivo springmvc-servlet.xml.

Criando o arquivo springmvc-servlet.xml

Para criar o arquivo, clique com o direito do mouse sobre o diretório WebContent/WEB-INF, selecionando no menu de contexto o item XML.

Se estiver utilizando o SpringSource Tool Suite, selecione no menu de contexto o item New>Other.

Na caixa de diálogo New, selecione Spring>Spring Bean Configuration File e prossiga no assistente.

Criando um arquivo de configuração do Spring

Figura 9 - Criando um arquivo de configuração do Spring

Na segunda etapa, mantenha o diretório WEB-INF selecionado e digite o nome do arquivo de springmvc-servlet.xml. Tirando “–servlet.xml”, o nome springmvc foi definido por você no arquivo web.xml da Listagem 1.

Definindo o nome do arquivo

Figura 10 - Definindo o nome do arquivo

Na terceira etapa, selecione os seguintes namespaces e seus respectivos XSDs:

beans – http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

context – http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd

Seleção do primeiro namespace do arquivo de configuração do Spring MVC

Figura 11 - Seleção do primeiro namespace do arquivo de configuração do Spring MVC

Listagem 2 – Configurações do arquivo springmvc-servlet.xml

O arquivo springmvc-servlet.xml é lido graças ao seguinte trecho encontrado dentro do arquivo web.xml:

Com a classe org.springframework.web.servlet.view.InternalResourceViewResolver, pré-fixamos o caminho das páginas em /WEB-INF/jsp/ e com o sufixo “.jsp”. InternalResourceViewResolver é uma subclasse de UrlBasedViewResolver, que suporta JSTL, também usada em nossas views.

Como boa prática recomendada pelo Spring, colocamos as páginas JSP dentro do diretório WEB-INF, impedindo assim seu acesso direto, manualmente, através da URL.

Criando o Controller

Com o direito do mouse sobre  Java Resources:src, selecione no menu de contexto New>Class. Na caixa de diálogo New Java Class, digite o pacote e, em OlaMundoController no campo Name. Confime em Finish a criação da classe.

Criação da classe OlaMundoController

Figura 12 - Criação da classe OlaMundoController

Altere a classe como mostrado na Listagem 3.

Listagem 3 – A classe OlaMundoController

Desde a versão do Spring MVC 2.5, podemos declarar uma classe controller utilizando simplesmente a anotação @Controller, de org.springframework.stereotype.Controller. Esta anotação permite que o Spring faça uma varredura automatica nas classes através do elemento <context:component-scan>.

Através da anotação @RequestMapping, definimos o caminho HTTP que será utilizado na aplicação, sendo mapeada pela classe. Na prática, todas as chamadas à aplicação contendo “/ola” serão analisadas pela classe controller.

DispatcherServlet (configurado no arquivo web.xml – Listagem 1) é o responsável por receber todas as requisições do cliente, executando a parte comum destes pedidos e delegando implementações específicas para os controllers. Este servlet é responsável por ler todas as configurações e usar a leitura de componentes deste framework.

Após DispatcherServlet receber o pedido e fazer o seu trabalho, ele tenta encontrar um controller, usando a interface HandlerMapping (implementada pelos objetos que definem um mapeamento entre requisições e manipulações).

Ao encontrar o controller, o método handleRequest(HttpServletRequest request, HttpServletResponse response) é chamado com a responsabilidade do pedido e, caso seja necessário, retorna um adequado ModelAndView.  Como padrão, uma instância de ModelAndView consiste em um nome da view e um Map, que contém nomes do bean e objetos correspondentes (como um comando ou formulário, contendo dados).

No caso, o Controller chama a view ola e passa mensagem com o valor de “Conhecendo o Spring MVC 3.0”.

Criando a View

Clique com o direito sobre o diretório WebContent/WEB-INF e selecione, no menu de contexto, o item New>Folder. Chame este diretório de jsp. Estamos fazendo isso porque será onde adicionaremos a página JSP. Este nome foi configurado no arquivo springmvc-servlets.xml, conforme a Listagem 2 no elemento <property value=”/WEB-INF/jsp/”/>.

Clique novamente com o direito do mouse, só que, desta vez,  sobre o diretório jsp recém criado, selecionando New>JSP.

Na caixa de diálogo chame de ola.jsp e clique no bota Finish. Altere como mostrado na Listagem 4.

Listagem 4 – A View ola.jsp

Para visualizar a página, digite em seu navegador:

http://localhost:8080/ConhecendoSpringMVC/ola

Resultado da saída gerada pelo Spring MVC 3.0

Figura 13 - Resultado da saída gerada pelo Spring MVC 3.0

O projeto

O resultado final de todos os arquivos criados e configurados no projeto será como mostrado na Figura 14.

Figura 14 – O projeto completo

Figura 14 – O projeto completo


[¹] Veja mais sobre IoC e DI no site do Martin Fowler: http://martinfowler.com/articles/injection.html

Tags: , , ,


fev 21 2010

JavaServer Faces 2.0 na Prática – Parte 3

Category: JSF 2.0Edson Gonçalves @ 3:55

Olá, tudo bom? Como vão vocês?

Este artigo é o terceiro de uma série ao qual vou ensiná-los a trabalhar com o JavaServer Faces 2.0.

Nesta terceira parte iremos conhecer melhor o framework JavaServer Faces 2.0 e seu comportamento.

Dúvidas e críticas são bem vindas.

Conhecendo melhor o JavaServer Faces

Como pudemos  ver, o framework JSF é responsável por interagir com o usuário (cliente). Porém, o escopo de JSF é restringido à camada de apresentação. A persistência de dados e outras conexões back-end estão fora do escopo de JSF.

Se você está começando agora, recomendo voltar até a Parte 1 para melhor compreender este artigo.

Renderizando componentes

Ao chamar uma página JSF no navegador, o servidor inicia uma chamada a árvore de componentes do JSF para renderizar a página de acordo com o encontrado.

O servlet JavaServer Faces inicializa o código do framework e lê a página index.xhtml. Como esta página contém tags JSF, como <h:form />, <h:inputText />, <h:commandButton /> e <h:outputText />, cada uma possui uma classe tag handler associada. Quando a página é lida, as tags handles são executadas, de modo que cada uma colabora com a outra para construir o que chamamos de árvore de componentes. A Figura 1 mostra as tag handlers dos componentes utilizados no exemplo criado na Parte 2 do conjunto de artigos.

Figura 1 – Os componentes da aplicação de exemplo

Figura 1 – Os componentes da aplicação de exemplo

Após ler cada componente, a página HTML é devolvida ao navegador, que a renderiza. Todo e qualquer texto que não for uma tag JSF será passado adiante, onde as demais que não forem serão convertidas em HTML.

O processo de devolver a página no formato HTML ao navegador é chamado de encoding. Se olhar o código HTML gerado, verá que o objeto UIInput, por exemplo, procura o ID (unique ID) e o seu valor atual da expressão #{meuManagedBean.texto}. Por padrão, as strings de atributos ID, do HTML, são adicionadas pelo framework, podendo ser aleatórias. Caso não houver um ID na tag <h:form/>, como no exemplo desenvolvido, poderemos ter um ID como j_idt17:texto:

<input id=”j_idt17:texto” name=”j_idt17:texto” />

Se houver um atributo ID na tag <h:form/> (ex: <h:form id=”form1″ />), você terá como resultado o ID form1:texto na renderização da página:

<input type=”text” />

Se desejarmos retirar essa pré-definição de nome no atributo ID, basta adicionar seguinte atributo e seu valor na tag <h:form/>: prependId=”false”. O resultado tag <h:form/> completa ficaria assim:

<h:form prependId=”false”>

No encoding, o atributo ID gerado seria apenas o nome atribuído na tag pela propriedade id, como, por exemplo, na tag de entrada <h:inputText id=”texto” />, onde a renderização HTML seria:

<input type=”text” />

Depois de ocorrer o encoding, elas são enviadas ao navegador que agora as reconhece como uma página HTML. A Figura 2 ilustra esta transformação.

Figura 2 – Codificação e decodificação das páginas JavaServer Faces

Figura 2 – Codificação e decodificação das páginas JavaServer Faces

Do navegador para o servidor

Depois que o usuário receber a página, este a preenche como deve e submete o formulário ao servidor novamente. No caso do exemplo, o formulário é submetido pelo método HTTP POST, contendo o endereço da página e os dados do formulário.

Os dados no servidor são colocados em uma tabela hash, como ocorre normalmente em processamentos Servlet, que pode ser acessada por todos os componentes. O framework JSF permite que cada componente inspecione esta tabela em um processo chamado de decoding. Neste momento, cada componente decide como serão interpretados os dados do formulário.

O processo como um todo é chamado de Ciclo de Vida e será visto mais adiante, ainda neste artigo.

A arquitetura do JavaServer Faces

Para melhor compreensão, a seguir teremos um resumo de como funcionam as páginas JavaServer Faces:

A arquitetura Model-View-Controller

JSF conecta a apresentação e o modelo. Como vimos, um componente de apresentação pode ser unido a uma propriedade do Managed Bean de um objeto modelo:

<h:outputText value=”#{meuManagedBean.texto}”/>

O JSF opera como o controlador que reage ao usuário processando a ação e os eventos de alteração de valores, enquanto dirige o código para atualizar o modelo ou a apresentação. A invocação ao controlador ocorre através do componente <h:commandButton />.

Quando o botão é clicado e o formulário é enviado (submetido) ao servidor, a implementação JSF invoca o método para checar o bean do usuário. O componente <h:commandButton /> pode possuir um método que entra em ação para atualizar o modelo e devolver para a navegação o ID da próxima página a ser exibida.

Validações e Conversão de dados

Usuários entram com os dados em um formulário Web com um formato de texto. Podemos validar de forma padrão ou personalizada como serão aceitos estes textos (dados). Estas validações, assim como suas conversões, são feitas pelo conjunto de tags JSF Core, que incluímos da seguinte forma:

A biblioteca de tags Core pode ser incluída também em uma página JSP da seguinte forma:

<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f”%>

Para validar, por exemplo, o tamanho mínimo de caracteres aceitos, podemos fazer da seguinte forma:

Também podemos validar se um campo é obrigatório ou não, utilizando required=”true”:

<h:inputText value=”#{meuManagedBean.texto}” required=”true” >

Objetos de negócios também requerem informações como números, datas ou outros tipos de dados. Com JavaServer Faces podemos definir com as tags Core como serão os dados aceitos em um determinado campo, convertendo-os ou até mesmo personalizar a regra de conversão.

Um exemplo simples seria utilizar o <f:convertDateTime />, que faz com que o campo de entrada seja apenas um tipo de data e hora com o formato definido, que pode ser acrescido ao seu código da seguinte forma:

Manipulação de erros

O JSF utiliza regras de validação para campos como “este campo é obrigatório”. Claro que, quando os usuários entrarem com dados inválidos, preciamos exibir mensagens de erros mais apropriadas.

Os erros, tanto de validação, como de conversão, são tratados da mesma forma: uma mensagem é adicionada ao componente que não passou na verificação (seja validação ou conversão), onde a página atual é novamente exibida contendo uma frase do problema ocorrido.

As tags utilizadas para tais representações são: <h:message /> e <h:messages />. Os erros também podem ser lançados de forma personalizada utilizando o atributo validatorMessage ou requiredMessage. Para o exemplo, poderíamos ter algo assim:

Internacionalização

JSF fornece suporte à internacionalização como codificações de caractere e a seleção de pacotes de recursos.

A internacionalização no JSF 2.0 é possível de duas formas: faces-config.xml e a tag Core <f:loadBundle />.

Para uma internacionalização com o arquivo faces-config.xml, devemos adicionar este arquivo dentro do diretório WEB-INF. O conteúdo é mostrado na Listagem 1.

Listagem 1 – O arquivo faces-config.xml

O arquivo faces-config.xml é usado no JSF 2.0 principalmente para numerosas configurações globais de sua aplicação.

Os rótulos neste caso são colocados em arquivos .properties, onde o nome de cada arquivo possui _ABREVIAÇÃO DO IDIOMA como, por exemplo: rotulos_pt.properties. Crie os arquivos mostrados nas Listagens 2 e 3 dentro do pacote br.com.integrator.

Listagem 2 – O arquivo rotulos_en.properties

Listagem 3 – O arquivo rotulos_pt.properties

Para compreender como ficará seu projeto, a Figura 3 mostra onde estará cada um dos arquivos que o compõem.

Figura 3 – Estrutura de diretórios do projeto

Figura 3 – Estrutura de diretórios do projeto

As alterações na página index.xhtml são mostradas na Listagem 4 a seguir.

Listagem 4 – Alterações na página index.xhtml

Para visualizar as alterações, será necessário trocar o idioma padrão do seu navegador. No Mozilla Firefox, por exemplo, basta ir em Ferramentas>Opções>Conteúdo>Idiomas e clicar no botão Selecionar. Coloque o idioma diferente do que está usando como primeiro na ordem da lista de idiomas de preferência e confirme tudo. Dê um reload na página que verá as alterações.

Caso não queira usar uma declaração global dos recursos de localidades, podemos adicionar a tag <f:loadBundle  /> em cada página JSF. A seguir o trecho que poderá substituir a configuração global no arquivo faces-config.xml.

Nota: Das duas formas apresentadas para internacionalização de uma aplicação Web com o framework JSF, a versão com o elemento <resource-bundle />, encontrado no arquivo faces-config.xml, é a mais eficiente, pois é utilizado em todo o aplicativo e não somente na página configurada.

Componentes customizados

O desenvolvedor de componentes pode criar componentes sofisticados que são chamados pelos designers simplesmente colocando suas tags em suas páginas, ou arrastando-as caso sejam visuais. Um exemplo é pegar bibliotecas criadas, como de calendários, gráficos ou de upload de arquivos com barra de progresso e simplesmente adicionar na página desenvolvida.

Desde o JavaServer Faces 2.0, criar componentes customizados ficou mais fácil, com um recurso chamado de Composite Components (Componentes Compostos). Para exemplificar como funcionam os recursos de Composite Components, altere como nos passos a seguir seu projeto:

  1. Crie um diretório chamado de resources, no mesmo diretório onde se encontra a página index.xhtml.
  2. Dentro do diretório resources, adicione outro diretório chamado de componente.
  3. No diretório componente, crie uma página XHTML, chamada de component.xhtml,  com o conteúdo mostrado na Listagem 5.

Listagem 5 – Conteúdo do arquivo component.xhtml

Uma página de componente(s) no JSF 2.0 pode conter suporte aos componentes do JSF, a validação, converters e listeners. Além disso, qualquer outra tag HTML pode ser adicionada ao componente, incluindo também recursos de templates.

As tags utilizadas para criar componentes compostos no exemplo são: <composite:interface/> e <composite:implementation/>. Para utilizá-las, é necessário adicionar o seguinte namespace:

<html xmlns:composite=”http://java.sun.com/jsf/composite”>

A tag <composite:interface/> declara o contrato para um componente, ou seja, definimos quais são os atributos que o componente receberá. Os atributos são definidos dentro desta tag, com a tag <composite:attribute />, onde temos os atributos name e required. Em name colocamos o nome do atributo do nosso componente composto e definindo true, em required, definimos o atributo como de preenchimento obrigatório.

O exemplo mostrado possui um componente que terá os seguintes atributos obrigatórios, em ordem definidos na interface: identificacao, managedbean e qtdcaracteres.

A tag <composite:implementation/> é onde definimos o conteúdo do componente composto. Onde definir #{cc.attrs.x}, sendo que “x” é o nome do atributo do seu componente, será o local de substituição quando preencher o componente na página que o utilizar.

Para utilizar este componente, vá à página index.xhtml e altere seu conteúdo conforme a Listagem 6 a seguir:

Listagem 6– A página index.xhtml

Para utilizar o componente criado, você adiciona o seguinte namespace em sua página:

xmlns: comp=”http://java.sun.com/jsf/composite/componente

Observe que componente, no namespace, é o nome do diretório onde se encontra seu componente composto (o diretório fica dentro de resources caso não se lembre). O nome comp é dado por nós para chamar o componente. Podemos ter inúmeros componentes dentro de um diretório, assim como vários diretórios dentro de resources. Os agrupamos como acharmos melhor, de acordo com o conveniente no desenvolvimento de nossos aplicativos.

Para utilizar o componente, o chamamos assim: <comp:component/>. Onde component é o nome do arquivo .xhtml criado. Os atributos deste componente podem ser vários e os definidos como obrigatórios precisam ser preenchidos para que não ocorram erros.

Figura 4 – Da criação do componente até sua utilização e renderização na página

Figura 4 – Da criação do componente até sua utilização e renderização na página

Renderizadores Alternativos

Por padrão, JSF produz HTML em sua saída, mas é extensível o suficiente para produzir outros tipos de saídas como, por exemplo, WML ou XUL.

Ajax

JavaServer Faces possui atualmente uma comunicação Ajax padrão que torna-se totalmente transparente as chamadas cliente-servidor sem a necessidade de reload na página.

Para conhecer rapidamente o Ajax no JavaServer Faces 2.0, altere a página index.xhtml como mostrado na Listagem 7.

Listagem 7 – Alterações na página index.xhtml

Com algumas pequenas mudanças, sua aplicação passou a utilizar o recurso de Ajax.

O JSF 2.0 possui uma nova API JavaScript, ao qual pode chamar o servidor, enviando e recebendo dados. Nesta API JavaScript, temos o seguinte método:

jsf.ajax.request(source, event, options)

Este método envia e recebe os dados do servidor de forma assíncrona diretamente para os componentes da view. Você pode vê-lo no HTML renderizado.

A tag <f:ajax /> que utilizamos no exemplo pode ser substituída pela chamada direta à  jsf.ajax.request() da seguinte forma:

<h:commandButton value=”#{rotulo.enviar}”

onclick=”jsf.ajax.request(this, event,

{execute: ‘form1:texto’, render: ‘form1:saida’}); return false;” />

Em ambos os casos, seja com a tag <f:Ajax/> ou pelo script adicionado na tag, na renderização, o método recebe o elemento que está disparando a ação , que no geral é o próprio que o chama (this), o evento e um conjunto de parâmetros.

Neste conjunto de parâmetros existem duas propriedades: execute e render. Tanto o execute, como o render, recebem os IDs dos elementos HTML renderizados no cliente, ou seja, o ID dos componentes que passaram pelo encoding. O execute define o componente que será submetido ao servidor via Ajax e render qual componente receberá a resposta.

O Ajax padrão de JSF 2.0 é obtido pela tag <h:outputScript />. Esta tag, configurada como no exemplo, renderiza a tag HTML <script/>, que trás um JavaScript existente na biblioteca JSF 2.0. Os três atributos usados no exemplo são:

  • name – O nome do arquivo externo de JavaScript que, no caso, pertence a própria biblioteca de JSF 2.0;
  • library – A biblioteca usada;
  • target –  Onde será renderizada a tag <script/>, que no caso será por entre as tags <head/>, sempre no HTML.

Nota: O JavaScript contido no JSF 2.0 em questão está dentro do JAR jsf-impl.jar, em META-INF/resources/javax.faces/jsf.js. Veja mais a respeito sobre o JavaScript padrão de JSF 2.0 no seguinte link: https://javaserverfaces.dev.java.net/nonav/docs/2.0/jsdocs/index.html.

O MVC de JSF

Para que JSF funcione, registramos a classe FacesServlet no deployment descriptor (web.xml). Ao fazer este registro, os pedidos são controlados pela classe javax.faces.webapp.FacesServlet (o Controller do MVC), uma implementação de javax.servlet.Servlet, roteando o tráfego e administrando o ciclo de vida dos beans e componentes de interface do usuário (UI).

Figura 5 – O MVC do framework JSF

Figura 5 – O MVC do framework JSF

Os componentes UI são organizados em uma estrutura de árvore onde, cada componente, pode ser associado com os métodos e atributos de um bean. Cada componente também pode ser associado com uma função de validação ou classe.

Por trás, FacesServlet aceita pedidos de entrada e controla o objeto javax.faces.lifecycle.Lifecycle. Usando uma factory, ela cria um objeto do tipo javax.faces.context.FacesContext, que contém todos os processos.

O ciclo de vida do JSF

O objeto Lifecycle usa o objeto FacesContext em seis fases que compõem o ciclo de vida de uma aplicação JSF. Cada fase tem uma ação importante em sua aplicação e deve ser bem compreendida para que você possa manipular ao extremo sua interface e melhorar a legibilidade de seu desenvolvimento.

Figura 6 – Ciclo de vida do JavaServer Faces

Figura 6 – Ciclo de vida do JavaServer Faces

As seis fases são executadas na seguinte ordem:

  1. Restaurar Apresentação [1]– Esta fase inicia o processamento da requisição do ciclo de vida por meio da construção da árvore de componentes do JSF. Cada árvore de componentes possui um identificador único durante todo o aplicativo. O JSF constrói a apresentação da página e salva  na instância FacesContext para processamento das fases seguintes.
  2. Aplicar Valores Requisitados – Nesta fase, quaisquer novos valores inseridos são extraídos e armazenados por seus apropriados componentes. Se o valor do componente não for uma String, então ele é convertido para o seu determinado tipo. Se a conversão falhar, ocorrem diversas situações:
  1. 1. Uma mensagem de erro é gerada e associada com o componente;
  2. 2. Uma mensagem de erro é armazenada no FacesContext e depois mostrada posteriormente na fase de Renderizar a Resposta;
  3. 3. O ciclo de vida pula a fase de Renderizar a Resposta quando esta se completou.
  1. Processar Validações – Depois do valor de cada componente ser atualizado, na fase de processo de validações, os componentes serão validados naqueles valores, se necessário. Um componente que necessita de validação deve fornecer a implementação da lógica de validação. Por exemplo, em um carrinho de compras, podemos determinar a quantidade mínima a ser digitada e máxima. O valor requisitado é um inteiro (verificado na fase anterior) e, como passou pela fase 2, nessa fase pode ser barrado por estar além do determinado (com uma quantidade mínima ou máxima diferente da estipulada).
  2. Atualizar Valores do Modelo – Alcança-se essa fase após todos os componentes serem validados. Nesta fase são atualizados os dados do modelo do aplicativo. Na página em que foi criada para enviar um texto, a informação digitada foi armazenada no Managed Bean durante esta fase. Por ter passado pelo processo de validação, temos garantias que o valor armazenado  será garantido nessa fase. Entretanto, os dados podem violar a lógica de negócios, ao qual a validação ocorre na fase seguinte.
  3. Invocar Aplicação – Durante esta fase, a implementação JSF manipula quaisquer eventos do aplicativo, tal como enviar um formulário ou ir a outra página através de um link. Estes eventos são ações que retornam geralmente uma  string que está associada a uma navegação no qual se encarrega de chamar a página determinada.
  4. Renderizar Resposta – Esta é a fase final, ao qual é renderizada a página. Se este é um pedido inicial para esta página,  os componentes são acrescentados à apresentação neste momento. Se este é um postback,  os componentes já foram acrescidos à apresentação.  Se há mensagens de conversão ou erros de validação e a página contém um ou mais componentes <mensage /> ou um componente <messages />, estes serão exibidos.  Reciprocamente, se a página não contém um componente de mensagem,  nenhuma informação aparecerá.

Numa requisição a uma página JSF, podemos passar por todas essas fases ou por nenhuma, dependendo do tipo de pedido, de erros que ocorrem durante as validações, conversões e do tipo de resposta.

Uma requisição e uma resposta são consideradas faces request/response se contiverem tags JSF, assim como as que não as contém são chamadas de non-faces request/response. Uma non-faces request pode vir de um clique em um link, por exemplo.

Como já dito, toda requisição é recebida pelo FacesServlet e prossegue a passagem pelas fases (Lifecycle) até uma resposta ser retornada ao cliente.

O FacesServlet recupera uma instância de FacesContext, do FacesContextFactory, fornecendo uma implementação de LifeCycle. O processamento do ciclo de vida é então delegado a interface LifeCycle, a partir da chamada ao método execute. A implementação de LifeCycle inicia as fases do ciclo de vida. Se existir algum validador associado a algum campo do formulário este é inicializado nessa primeira fase. A árvore é armazenada pelo contexto e será utilizada nas fases seguintes. Também o estado do formulário é salvo automaticamente.

Testando o ciclo de vida

Para confirmar como todas as fases do ciclo de vida são usadas e quais são, basta criar um simples PhaseListener e mandá-lo gerar a saída antes e depois de cada fase.

Criando uma classe Phase Listener

Criar uma classe que implemente a PhaseListener exigem dois passos:

• Criar uma classe que implemente PhaseListener;

• Registrar esta classe no arquivo de configurações do JSF.

A classe PhaseListener deve implementa a classe javax.faces.event.PhaseListener.  A Listagem 8 demonstra como criar esta classe:

Listagem 8 – A classe PhaseListener

Para a classe da Listagem 8, três métodos são implementados: afterPhase(), beforePhase() e getPhaseId().

Os dois primeiros,  afterPhase()beforePhase(), definem o que ocorre ANTES e DEPOIS de cada fase.  Nestes métodos foram incluídos a capacidade de imprimir na saída console o que ocorreu.

O terceiro método, getPhaseId(), especifica  em  qual das fases é invocado este ouvinte (Listener) e PhaseId.ANY_PHASE menciona que será para todas as fases.

Com a classe criada, o próximo passo é registrar esta classe PhaseListener no arquivo de configurações do JSF (faces-config.xml).

Para fazer isso, no arquivo faces-config.xml,  adicionaremos os seguintes elementos do trecho a seguir:

Ao rodar a aplicação, haverá saídas no console de acordo com o uso da aplicação. A Figura 7 mostra tanto o uso da aplicação como sua saída no console, passando pelas seis fases do ciclo de vida.

Figura 7- Execução do exemplo e saída no Console resultante da classe PhaseListener

Figura 7- Execução do exemplo e saída no Console resultante da classe PhaseListener

Podemos testar o comportamento das fases enviando o formulário sem dados preenchidos ou preenchendo erroneamente. É uma forma de analisar de perto o ciclo de vida do framework JavaServer Faces.


[1] Defino aqui como Apresentação a tradução para View, que se refere ao Model-View-Controller, no qual traduzo como Modelo-Apesentação-Controle. Entretanto, a especificação JSF define como View o nome para uma página JSF. No decorrer dos artigos, sempre que me referir a View, estarei tratando da página JSF e não da palavra existente em MVC.

Tags: , , , ,


fev 09 2010

JavaServer Faces 2.0 na Prática – Parte 2

Category: JSF 2.0Edson Gonçalves @ 20:05

Olá, tudo bom? Como vão vocês?
Este artigo é o segundo de uma série ao qual vou ensiná-los a trabalhar com o JavaServer Faces 2.0.
Nesta segunda parte iremos conhecer e utilizar um Managed Beans.
Dúvidas e críticas são bem vindas.

Conhecendo o comportamento do  JavaServer Faces

Agora que já fizemos nossa primeira aplicação em JSF, é mais fácil de entender os serviços que o framework JSF oferece ao desenvolvedor.  Como pudemos ver, o framework JSF é responsável por interagir com o usuário (cliente) e fornece componentes para criar uma apresentação visual de uma aplicação Web, ou seja, o escopo de JSF é restringido à camada de apresentação. A persistência de banco de dados e outras conexões de back-end estão fora do escopo de JSF.

A arquitetura do JavaServer Faces, em um alto nível, se assemelha ao mostrado na Figura 1. Aplicações JSF utilizam como padrão a interceptação HTTP via Servlet Faces e produz HTML. Esta mesma arquitetura permite “plugar” novos elementos, gerando outras características, possibilitando criar páginas usando eventos, listeners e componentes como o seu irmão Java Swing.

A arquitetura JavaServer Faces

Figura 1. A arquitetura JavaServer Faces

A Figura 1 mostra a arquitetura rica e flexível existente no JSF, onde:

  • FacesServlet – é o servlet principal para a aplicação e, opcionalmente, você pode ter o arquivo de configuração faces-config.xml[1].
  • Renderers –  são os responsáveis por exibir um componente e traduzir uma entrada de valor realizada por um usuário em componente.
  • Páginas XHTML, JSP – o JavaServer Faces permite mais de um tipo de arquivo para renderizar seus componentes (PDL – Page Declaration Language[2]), como páginas JSP ou Facelets.
  • Converters – convertem o valor de um componente (como datas, moedas, porcentagem e outros) dando-lhes novos formatos.
  • Validators – responsáveis por validar a entrada ocorrida no componente pelo usuário.
  • Managed Bean – a lógica do negócio é gerenciada pelos managed beans, que controlam inclusive a navegação por entre páginas.
  • Ajax – Tanto o envio como o recebimento de dados podem ser feitos via Ajax, sem a necessidade de reload na página do usuário.

[1] Este arquivo só se tornou opcional na versão 2.0 ou superior.

[2] PDL herda a funcionalidade do núcleo de dois conhecidos projetos JSF: Facelets e JSFTemplates. Entre todos os outros recursos, permite criar novos componentes JSF de forma declarativa, sem a criação de um grupo de classes Java como era nas versões anteriores do JSF.

Compreendendo o comportamento da primeira página JSF criada

Assim como ocorre com outras bibliotecas de tags, o JavaServer Faces é configurado através da diretiva taglib, onde existem as bibliotecas que manipulam o HTML e a Core.

Para usar as tags HTML personalizadas que representam componentes JavaServer Faces, você precisa da diretiva taglib mostrada a seguir, geralmente posicionadas no topo de cada página JSP, como de costume no uso dessa diretiva.

<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h”%>

No caso da utilização do Facelets, onde as páginas são XHTML’s, você terá a inclusão da tag personalizada HTML de JSF dessa forma:

<html … xmlns:h=”http://java.sun.com/jsf/html”>

Nota: Com a evolução, o desenvolvimento em JSF atualmente pode utilizar a versão com XHTML descartando a anterior, uma vez que se adéqua melhor ao modelo Web 2.0.

Dentre as tags JSF adicionadas na página, a tag <h:form />, representa um componente UIForm e cria um formulário para envio de dados pelo JSF. No HTML gerado, temos a tag <form/> para que o browser a compreenda.

A tag <h:outputText /> , representando um componente UIOutput que exibe valores, é a responsável pela geração do texto renderizado na página do usuário que, na grande maioria das vezes, é dinâmico. No atributo value você adicionou o texto diretamente, mas poderia adicionar a JSF EL (JavaServer Faces Expression Language), visto mais adiante, referente ao Bean criado, dando assim o retorno ao browser de um valor dinâmico produzido por uma entrada ou vindo do banco de dados.

A página no Browser

A página criada no aplicativo poderá ser aberta através do seguinte endereço também:

http://localhost:8080/TrabComJSF/faces/index.xhtml

Isso ocorre porque adicionamos a seguinte configuração no deployment descriptor (web.xml):

Os itens em destaque mostram que o Servlet FacesServlet, usado para renderizar os componentes JSF, é acionado quando temos “/faces/” antes do nome da página.

Adicionando um bean ao projeto

Na primeira página JSF que criou, você simplesmente adicionou o texto diretamente na tag HTML JSF  <h:outputText />.

Desta vez, você irá adicionar o conteúdo através de um Managed Bean, que nada mais é que uma classe JavaBean comum. A Listagem 1 mostra o conteúdo do Managed Bean que deverá ser feito:

Listagem 1 – A classe MeuManagedBean.java

A estrutura de diretórios com o Managed Bean

Sua estrutura de diretórios deverá ser similar ao mostrado na Figura 2, onde apresentamos a classe MeuManagedBean.java compilada:

Estrutura de diretórios do projeto TrabComJSF

Figura 2. Estrutura de diretórios do projeto TrabComJSF

Alterando a página do projeto

Vá até a página index.xhtml e altere a tag JSF  <h:outputText /> da seguinte forma:

<h:outputText value=”#{meuManagedBean.texto}” />

Ao alterar a tag <h:outputText/>, o atributo value recebeu agora os delimitadores #{…}. Estes delimitadores são indicações de expressão ao qual ligam o componente JSF ao Managed Bean e seu atributo get correspondente, neste caso.

No JavaServer Faces 2.0, usamos a anotação @ManagedBean, de javax.faces.bean.ManagedBean, para registrar a classe como sendo uma Managed Bean onde, através do atributo name, damos o nome que será acessível pelos componentes das páginas JSF. No caso, chamamos de meuManagedBean.

O conteúdo é exibido pelo método público getTexto(), responsável por enviar as informações do Managed Bean para a página JSF e exibi-las através da tag <h:outputText />. A Figura 3 mostra como funciona essa integração.

Um managed bean possui um escopo onde, no caso, está definido como por requisição[3]. Este escopo é definido na anotação @RequestScoped, de javax.faces.bean.RequestScoped.


[3] Isso indica que as informações transmitidas serão recebidas e permanecerão apenas na página ao qual foi requisitada. Se você navegar para outra página, estas informações se perdem.

Componente da página JSF lendo o Managed Bean

Figura 3. Componente da página JSF lendo o Managed Bean

Os Beans em JSF

Um bean em Java é uma classe que expõe atributos/propriedades e eventos em um ambiente como o JSF. Um atributo é nada mais que uma variável nomeada com um determinado tipo que pode ser lido ou escrito. No bean, existe a convenção de declarar tais atributos como sendo do tipo privado e expô-los através de métodos públicos que encapsulam seus valores com as iniciais: set e get que servem para atribuir um valor e para pegar este valor respectivamente.

Utilizando Getters e Setters em um Managed Bean

Para compreender melhor estas características, vamos modificar novamente o exemplo de modo que possamos enviar dados de um campo e recebê-los.

Rascunho da representação final do exemplo

Figura 4. Rascunho da representação final do exemplo

Altere a página index.xhtml como mostra o trecho a seguir:

E altere o Managed Bean MeuManagedBean adicionando o método setText() e modificando o método getText() como mostra o trecho a seguir:

Pronto, basta rodar o exemplo que verá o resultado.

Submissão do texto da página para o Managed Bean e retornando

Figura 5. Submissão do texto da página para o Managed Bean e retornando

Na próxima Parte

Desta vez você utilizou mais dois componentes: <h:inputText /> e <h:commandButton />. O primeiro permite a inserção de dados. O atributo id é o nome atribuído ao componente e o value possui a expressão JSF que contém a ligação entre o componente e o atributo no Managed Bean. O segundo componente, o <h:commandButton />, teve o atributo value que representa o texto a ser exibido no componente e action, que chama um método no servidor e, se não houver método, recebe como valor uma string qualquer, que pode indicar navegação para outra página ou não.

Na Parte 3 de JavaServer Faces 2.0 na Prática teremos uma visão geral da arquitetura do framework, com pequenos exemplos funcionais em alguns dos seus aspectos.

Tags: , , , ,


fev 03 2010

JPA 2.0 na Prática – Parte 2

Category: JPA 2.0Edson Gonçalves @ 14:13

Olá, tudo bom? Como vão vocês?

Este artigo é o segundo de uma série ao qual vou ensiná-los a trabalhar com a Java Persistence API 2.0 (JPA 2.0).  Dúvidas e críticas são bem vindas.

Os primeiros passos na JPA

Com o ambiente configurado, agora podemos  configurar a JPA e dar nossos primeiros passos em sua execução, entendendo como funciona e o que podemos fazer.

Esta parte do artigo está baseada na configuração, criação da entidade e manipulação básica do banco de dados.

Caso você tenha chegado agora, a Parte 1 do artigo ensina como configurar o seu ambiente de desenvolvimento e testes.

Configurando o arquivo persistence.xml

Ao criar o projeto, também foram criados um diretório e arquivo. Note o arquivo chamado persistence.xml,  encontrado no diretório META-INF, dentro de src.

Abra o arquivo persistence.xml e verá que o Eclipse IDE possui um editor do arquivo.

Sua estrutura básica é como mostrada na Listagem 1 abaixo:
Listagem 1 – O arquivo persistence.xml

Ela pode ser visualizada no Editor do Eclipse, em Source.

Configurando a conexão com o banco de dados

No editor do Eclipse, vá na aba Connection, em persistence.xml.

Adicionando as configurações de conexão ao persistence.xml

Adicionando as configurações de conexão ao persistence.xml

Comece alterando para Resource Local em Transaction type.

Esta pequena alteração adiciona o atributo transaction-type com o valor “RESOURCE_LOCAL” em <persistence-unit/> no arquivo persistence.xml.  O atributo transaction-type está definindo que a unidade de persistência terá sua integridade gerida  através da API local (RESOURCE_LOCAL), que é o nosso caso, onde não haverá um servidor de aplicativos Java EE por enquanto envolvido para transações JTA (Java Transaction API).

Mais abaixo, em EclipseLink Connection Pool, clique em Populate from Connection.

Adicionando os parâmetros de conexão no arquivo persistence.xml

Adicionando os parâmetros de conexão no arquivo persistence.xml

Ao abrir a caixa de diálogo Connection Selection, selecione a conexão do MySQL que fez na criação do projeto e confirme.

Conexão do MySQL feita na criação do Projeto

Conexão do MySQL feita na criação do Projeto

Ao retornar ao arquivo persistence.xml, os dados pertencentes ao banco de dados estarão preenchidos.

Configurações para a conexão ao banco de dados

Configurações para a conexão ao banco de dados

Esta mudança da conexão alterou o arquivo persistence.xml da seguinte forma:

Na JPA 2.0, algumas propriedades foram padronizadas. As propriedades que foram adicionadas ao arquivo persistence.xml são padrões para se conectar ao banco de dados. Veja o que significa cada uma delas:

  • javax.persistence.jdbc.driver — o nome do driver da classe totalmente qualificado
  • javax.persistence.jdbc.url — URL específico do driver
  • javax.persistence.jdbc.user — usuário do banco de dados para a conexão
  • javax.persistence.jdbc.password — senha do banco de dados para a conexão

Vá agora até a aba Logging e, em Logging level, altere para All. Isso tornará visível todas as operações que fizemos, utilizando a JPA, no Console do Eclipse.

Alterando o nível de logging para ALL

Alterando o nível de logging para ALL

Infelizmente, nem todas as propriedades de persistence.xml foram padronizadas. A seguinte propriedade foi adicionada ao arquivo:

<property name=“eclipselink.logging.level” value=“ALL”/>

Ainda em persistence.xml, vá até a aba Schema Generation.  Nesta aba temos DDL generation type. Como não fizemos nenhuma tabela no banco de dados, teremos que criá-la ao executar nossa primeira entidade.

Temos três opções:

  • None – não ocorre nada;
  • Create Tables – cria as tabelas baseando-se nas informações contidas nas entidades;
  • Drop and Create Tables – exclui e cria as tabelas através das informações contidas nas entidades;

Para o nosso trabalho inicial, vamos manter um ciclo de criação e exclusão,  selecionando Drop and Create Tables.

Gerando tabelas através da configuração de persistence.xml

Gerando tabelas através da configuração de persistence.xml

As últimas alterações incluíram a seguinte propriedade:

<property name=“eclipselink.ddl-generation” value=“drop-and-create-tables”/>

Com estas mudanças, temos tudo pronto para trabalhar com a JPA.

Criando sua primeira entidade

Clique com o direito do mouse sobre src, do seu projeto JPA. Selecione no menu de contexto New>Entity.

Criando uma entidade JPA no Eclipse IDE

Criando uma entidade JPA no Eclipse IDE

Na caixa de diálogo New JPA Entity, preencha Java package e Class name, no caso: br.com.integrator e Categoria, respectivamente. Mantenha Entity em Inheritance e clique no botão Next.

Criando a classe/entidade Categoria

Criando a classe/entidade Categoria

Na segunda etapa, definimos o nome da tabela que será utilizada pela entidade Categoria e seus respectivos campos/colunas.

Segunda etapa da criação da Entidade JPA

Segunda etapa da criação da Entidade JPA

O Eclipse IDE, através do seu assistente, irá manter o nome da tabela como padrão existente ao nome da entidade. Desmarque Use default e altere para categorias em Table name.

Esta pequena alteração informa que a entidade Categoria está ligada a tabela categorias do banco de dados.

Alteração do nome da tabela para o banco de dados

Alteração do nome da tabela para o banco de dados

Abaixo você vai encontrar Entity fields. Clique em Add para adicionar as os atributos que existirão na entidade Categoria e seus respectivos tipos.

Detalhe da adição de atributos na entidade Categoria

O diálogo Entity Fields possui Type para colocar o tipo ( que também é acessível com Ctrl+Space) e o nome.

Adicionando um atributo

Adicionando um atributo

Os atributos da entidade são mostrados na Figura abaixo:

Atributos da entidade Categoria

Atributos da entidade Categoria

Veja que foi marcado id como key. Isso fará com que este atributo/campo seja a chave primária.

Diálogo completamente preenchido

Diálogo completamente preenchido

Com tudo preenchido, clique no botão Finish para gerar a classe Categoria com as devidas anotações que a fará uma Entidade da JPA.

A classe/entidade Categoria possui a estrutura como mostrado na Listagem 2 após sua geração:

Listagem 2 – A entidade Categoria

As entidades, na especificação da JPA, são POJOS (Plain Old Java Objects ), onde podemos alocar com o operador new, assim como faríamos com qualquer outro objeto Java simples. As instâncias de uma classe do tipo entidade não se tornam persistentes até estarem associadas a um EntityManager.

No arquivo persistence.xml, verá a classe adicionada em General>Managed Classes.

Detalhe de Managed Classes em persistence.xml

Detalhe de Managed Classes em persistence.xml

No XML de persistence.xml, haverá a seguinte linha adicionada:

<class>br.com.integrator.Categoria</class>

O elemento <class/> lista explicitamente as classes que são consideradas entidades no persistence.xml.

Para finalizar, vá até a classe Categoria. Na view JPA Structure, clique em id. Marque Primary key generation na view JPA Details e selecione Identity em Strategy. Isso informa a entidade que o campo da chave primária é auto-incrementado e, portanto, gerado pela tabela do banco de dados.

Definindo a estratégia de auto-incremento no campo id da entidade

Definindo a estratégia de auto-incremento no campo id da entidade

Na classe veremos a seguinte anotação: @GeneratedValue(strategy = IDENTITY), onde IDENTITY é de javax.persistence.GenerationType.

Testando a JPA

Antes de explicar qualquer coisa, vamos fazer um teste para saber se está tudo corretamente funcionando, simplesmente chamando a persistence-unit através de uma simples classe Java com um método main().

Crie uma classe no próprio projeto JPA , chamando-a de TesteDaJPA. Coloque em um pacote diferente do qual vem usando e marque public static void main(String[] args). Confirme a criação da classe no botão Finish.

Criação da classe de testes

Criação da classe de testes

Altere a classe TesteDaJPA conforme a Listagem 3:

Listagem 3 – A classe TesteDaJPA

Execute a classe através do menu Run>Run As>Java Application.

Graças à configuração que fizemos de logging no arquivo persistence.xml (em <property name=“eclipselink.logging.level” value=“ALL”/>) , possuímos uma saída bem detalhada do que ocorreu ao gerar este simples teste.

Assim que iniciada a classe, veremos a saída contendo a conexão ao banco de dados:

Entre a saída, veremos que, devido a configuração no persistence.xml (em <property name=“eclipselink.ddl-generation” value=“drop-and-create-tables”/>) , primeiro houve uma tentativa de fazer um drop table na tabela categorias. Como não existia tal tabela, veremos este erro:

Por fim, será possível ver que ocorre a desconexão ao banco de dados.

A tabela gerada no banco de dados

Ao entrar no banco de dados, veremos que a simples classe anotada se transformou em uma tabela. Evidentemente que o POJO, sem a devida configuração no arquivo persistence.xml, antes da sua chamada pela classe executora que fizemos de teste, não teria esse poder.

A tabela gerada no MySQL

A tabela gerada no MySQL

Graças a anotação @Table, pudemos dar o nome da tabela que seria gerada, através do atributo name.

Atributos convertidos em colunas

Observe que cada atributo da classe se transformou em uma coluna na tabela. A coluna chave, tida por ID, foi gerada graças à anotação @Id. Além disso, o MySQL considerou esta coluna como auto-incrementada, ou seja, ela possui um modificador que incrementa em um toda vez que uma informação é inserida na tabela. Isso é automático e gerenciado pelo banco de dados. A anotação @GeneratedValue foi a responsável pela geração do auto-increment do MySQL.

Os tipos de cada coluna são gerados pelo similar em Java. Logo, Long se transformou em bigint e String em varchar. Cada tipo de coluna, na tabela do banco de dados, possui também um tamanho definido na sua criação. Como não especificamos isso na classe Categoria, através de anotações, a tabela foi gerada utilizando o tamanho máximo obtido pelo tipo, isso no banco de dados em questão. Logo, Long se transformou em bigint(20) e String em varchar(255).

Na próxima parte

Na Parte 2 da série JPA 2.0 na Prática finalmente fizemos a configuração da JPA, possibilitando a conexão ao banco de dados. Também foi possível gerar uma tabela baseada em uma entidade da JPA através de um pequeno teste de utilização.

Em JPA 2.0 na Prática – Parte 3, começaremos a compreender a Entidade em questão, suas várias anotações e implicações no banco de dados.

As entidades, na especificação da JPA, são POJOS (Plain Old Java Objects ), onde podemos alocar com o operador new, assim como faríamos com qualquer outro objeto Java simples. As instâncias de uma classe do tipo entidade não se tornam persistentes até estarem associadas a um EntityManager.

No arquivo persistence.xml, verá a classe adicionada em General>Managed Classes.

Tags: , , , , ,