Desenvolvendo uma aplicação Java EE 6 com Eclipse (parte 3)

Transcrição

1 [linu.com.br] - [parte 1] - [parte 2] - [parte 3] - [parte 4] - lgapontes@gmail.com Desenvolvendo uma aplicação Java EE 6 com Eclipse (parte 3) Por fim, a camada de apresentação. Clique aqui caso você queira ler a 1ª parte desse material. Ou clique aqui para ler a 2ª parte. Para acessar a 4ª parte, clique aqui. Vamos lá... Grandes novidades do JSF 2.0 Vamos primeiro salientar os novos recursos que o Java EE 6 oferece para a camada View de sistemas enterprise. Todos esses recursos foram projetados dentro da nova versão do JavaServer Faces: a JSF 2.0. As anotações oferecidas pelo pacote javax.validation.constraints nós já havíamos comentado. Trata-se de anotações que são inseridas no modelo do sistema e validadas na comunicação entre as páginas e os Beans. Utilizamos nesse projeto, como exemplo, as Veremos na prática como as mensagens associadas ao não cumprimento dessas anotações serão disparadas, automaticamente, para o componentes de mensagens (como o <h:messages>) do JSF. A versão anterior do JSF (JSF 1.2) trabalhava com taglibs JSF embutidos em páginas JSP. Essa nova versão, porém, sugere que toda a camada view será construída em Facelets, com arquivos XHTML. O Facelets já era um conhecido de aplicações EE 5, disponível através de libraries (veja mais detalhes num interessante material disponibilizado pelo site JavaWora em Os arquivos XHTML também oferecem mais conformidade e padronização para a construção de páginas HTML (veja Ou seja, agora, o que usávamos por conta própria passou a ser encorajado pela própria convenção do Java EE 6. O suporte a AJAX, que antes era possível com o uso do Ajax4Jsf do pacote RichFaces (JBoss), agora está amplamente atendido pela própria especificação JSF. Foi também acrescido recursos de navegação condicional (que coloca um IF na <navegation-rule>) e navegação implícita. Vou ressaltar a flexibilidade da navegação implícita. Antes, a construção de <navegation-rule> para conduzir a navegação entre duas páginas JSF era necessária. Agora, com a navegação implícita, caso não exista uma regra a ser considerada para o outcome definido na JSF, uma página com o mesmo nome (acrescida com.xhtml) será, automaticamente buscada (se você boiou nessa explicação, não se preocupe, veremos isso na prática mais adiante). Outro importante detalhe gira em torno do suporte natural ao GET. Antes, para se construir páginas JSF bookmarkables, nós precisávamos fazer muitos intervenções na codificação natural do JSF. Agora, com o suporte ao GET, isso se tornará muito mais fácil - você verá como! Só para constar, uma página pode ser considerada bookmarkable quando o usuário pode guardá-la, de forma plena, na opção Favoritos de seu navegador. Como o JSF só dava suporte ao POST, isso não era possível. Existem ainda outros recursos que precisariam de maior atenção, com é o caso do Project Stages (definição de qual estágio a aplicação se encontra - um possível estágio, por exemplo, seria o de Development, para indicar que estamos desenvolvendo a aplicação e assim, um número maior de detalhes seria apresentado nos erros). Neste artigo, porém, vamos tratar dos principais recursos que essa fantástica versão do JSF nos oferece. Inclusive, o recurso que eu acho mais pertinente, eu ainda não comentei. Não precisamos mais indicar quais Beans ficarão acessíveis na JSF (via EL) pelo faces-config.xml. Agora existem anotações específicas para isso! Veremos isso na prática também. Bom gente, achei interessante divulgar um pouco mais sobre o assunto para mostrar como a Sun (aliás, a Oracle) investiu bastante nos recursos da camada View nessa nova versão do Java EE. Mas chega de blablabla... voltemos ao projeto! Desenvolvendo a camada View (projeto SuperForumWeb) O primeiro passo é apagar a página index.jsp. Ham? Bom, nosso Eclipse ainda não está 100% Java EE 6, portanto, quando criamos nosso projeto SuperForumWeb, uma página index.jsp foi automaticamente criada. Vamos excluí-la. Entre no projeto SuperForumWeb, na pasta WebContent. Clique com o botão direito sobre o arquivo index.jsp e selecione a opção delete. Clique em OK Vamos agora criar um pacote para a camada View. Clique com o botão direito sobre o projeto

2 SuperForumWeb, selecione New, Package. Dê ao pacote o nome de br.com.linu.forum.view. Esse pacote conterá todas as classes dessa camada. Assim como nas versões anteriores do JSF, é comum a construção de Beans associados às páginas JSP. Aqui, a ideia permanece a mesma, porém, não será mais necessário trabalhar com o arquivo facesconfig.xml para definir os Managed Beans e as páginas serão construídas em XHTML. Importante: Não precisaremos declarar os beans gerenciados, mas vamos codificar um Exception Handler (vou explicar em breve) e para ele funcionar, sua declaração será necessária no faces-config.xml. Importando a biblioteca Commons Lang Bom, em determinado momento da camada de apresentação, nós precisaremos percorrer toda a sequência de uma Exception até encontrar a exceção causadora do disparo. Isso poderia ser, de certa forma, facilmente implementado. Porém, como bons programadores OO, não vamos reinventar a roda! Faremos uso da classe ExceptionUtils do pacote Commons Lang da Apache Commons. Nesse momento mostrarei como configurar o Eclipse e o Glassfish para utilizarem esse pacote. Entre no endereço Clique no link commons-lang-2.5-bin.zip para baixar o arquivo de mesmo nome. Após terminado o download, você deverá descompactar o arquivo. Vários arquivos serão descompactados dentro de uma pasta chamada commons-lang-2.5. Vamos utilizar o arquivo commons-lang-2.5.jar Com o servidor Glassfish desligado, copie o arquivo commons-lang-2.5.jar para o diretório sges-v3/glassfish/lib (onde sges-v3 é o diretório de instalação do Glassfish). O servidor de aplicação já estará configurado na próxima vez que for iniciado. Vamos agora configurar o ambiente de desenvolvimento. No Eclipse, clique no menu Window, sub-menu Preferences.

3 Vamos definir as bibliotecas do usuário. Clique (na TreeView à esquerda da janela) na opção Java, Build Path, User Libraries. Detalhe: não estranhe caso seu Eclipse não possua a definição (javaee, jdbc e richfaces) igual à imagem. Essa imagem foi extraída de um Eclipse que já era utilizado para outros projetos. Clique então no botão New... Defina o valor de User library name como commons-lang e clique em OK

4 Selecione (no quadrado à direita) a definição commons-lang e clique no botão Add JARs... No FileChooser, selecione o arquivo commons-lang-2.5.jar no local onde o ZIP foi descompactado. Clique em Abrir

5 Dessa forma, nosso Eclipse já possui uma User Library pronta para o uso do Commons Lang. Vamos adicioná-la ao projeto Web. Clique com o botão direito sobre o projeto SuperForumWeb, selecione a opção Build Path, item Configure Build Path...

6 Na Aba Libraries, clique no botão Add Library... Selecione a opção User Library e clique em Next

7 Marque a biblioteca commons-lang e clique em Finish Dessa forma nosso projeto já está configurado para trabalhar com a Commons Lang. Clique em OK Projetando um Exception Handler Pessoal, precisamos entender alguns conceitos de funcionamento do servidor de aplicação EE antes de programarmos esses recursos. Tenha em mente que, todo o gerenciamento dos beans será realizado pelo servidor de aplicação Glassfish. Image, por exemplo, que nosso projeto SuperForumWeb resgatou o Session

8 Bean br.com.linu.forum.services.servicefacade (implementado do projeto SuperForumEJB. Esse Session Bean estará sendo integralmente gerenciado pelo servidor EE. Beleza! Veja agora o código abaixo: public void createtopic(topic topic) throws BusinessException { topic.setcreationdate( new Date() ); business.create( topic ); Esse código foi implementado na classe TopicService e será utilizado para cadastrar tópicos. Essa classe, contudo, será acessada pelo método gettopicservice() do nosso SessionBean ServiceFacade. Em nosso projeto SuperForumWeb criaremos classes associadas aos XHTML e cada uma delas fará uma chamada (via JNDI) ao EJB publicado. Abaixo temos um exemplo do código de uma dessas classes (não se preocupe em implementá-la agora, faremos isso com detalhes em seguida). private ServiceFacade facade; (...) public void create(actionevent event) { try { facade.gettopicservice().createtopic(this.topic); catch (BusinessException e) { /* Nada precisa ser feito aqui */ (...) Conforme comentamos, o ServiceFacade foi obtido via Veja que fazemos uso do método createtopic() dentro do método create(). Daí, precisamos entender algumas questões: Se o ServiceFacade está sendo gerenciado pelo Glassfish, esse método pegará (via catch) uma BusinessException disparada? Não. Minha nossa senhora!!!! E agora?... O que acontece quando uma BusinessException é disparada pelo método createtopic()? Pois é, em nossa aplicação SuperForumWeb, as exceções disparadas pelos Session Beans serão capturadas por um Exception Hander padrão.

9 Então o que vamos fazer agora? Vamos precisar criar um ExceptionHandler específico para capturar uma AbortProcessingException (exceção gerada pelo servidor de aplicação quando ocorre uma Exception nos métodos dos Session Beans), percorrer toda sua cadeia de exceções (através do recursos oferecidos pelo Commons Lang da Apache) até encontrar uma BusinessException. Em seguida, enviaremos para as páginas XHTML a mensagem contida na exceção de negócios. Caraca véi!!! Tudo isso? Bom, ainda nessa versão do Java EE, a codificação manual das Exceptions Handlers são necessárias. Em frameworks já consagrados no mercado (e, aliás, mais antigos) como o Struts, pode-se fazer isso via configuração em arquivo XML. Aqui, porém, não é possível. Como vamos fazer? Ai que entra a parte boa: a programação! Vamos lá! O servidor EE busca sua Exception Handler numa fábrica de Exceptions Handlers (um pouco de Design Pattern GoF pra variar). Nós vamos então criar nossa própria handler de exceções chamada ExceptionHandlerForum e distribuí-la para o Glassfish através uma fábrica (também implementada por nós) chamada ExceptionHandlerForumFactory. Por fim, vamos configurar o arquivo faces-config.xml para indicar que nossa aplicação possui uma fábrica de handlers própria. Ufa! Vamos criar um novo pacote. Clique com o botão direito sobre a aplicação SuperForumWeb, selecione a opção New, Package. Defina o nome do pacote como br.com.linu.forum.view.util Nesse pacote nós vamos criar três classes: ExceptionHandlerForum, ExceptionHandlerForumFactory e ViewUtilities. Vamos iniciar com a classe de utilidades (que será simples). Crie uma classe chamada ViewUtilities no pacote br.com.linu.forum.view.util package br.com.linu.forum.view.util; import java.io.serializable; import java.text.dateformat; import java.util.date; import java.util.locale; import javax.faces.application.facesmessage; import javax.faces.context.facescontext; public class ViewUtilities implements Serializable { private static final long serialversionuid = 1L; public static String formatdate(date date) { if ( date == null ) return null; Locale ptbr = new Locale("pt", "BR"); DateFormat dateformat = DateFormat.getDateInstance(DateFormat.MEDIUM, ptbr); return dateformat.format( date ); public static void sendmessage(string message) { FacesContext.getCurrentInstance().addMessage ( null, new FacesMessage( FacesMessage.SEVERITY_WARN, null, message ) );

10 Essa classe oferece recursos estáticos para as outras classes da camada View. O método formatdate() formata uma data, através de Internationalization, para o padrão brasileiro. Existem muitas maneiras de fazer isso. Como nossa simples aplicação só precisa desse recurso para as datas, optei em fazer assim - totalmente Java SE... hehehe! O outro método, sendmessage() é o que nos interessa no momento. A String obtida do getmessage() da BusinessException capturada deverá ser exibida na tela XHTML. Através do addmessage() obtido da instância do FacesContext podemos fazer isso. Observe que todas as mensagens do nosso sistema serão SEVERITY_WARN (mensagens de atenção). Em aplicações maiores convém habilitarmos recursos para o uso de mensagens de aviso e erro. Agora que nossa extensa classe de utilidades ficou pronta, vamos criar o mecanismo de Handler. Crie uma nova classe chamada ExceptionHandlerForum dentro do pacote br.com.linu.forum.view.util. O código dessa classe é apresentado abaixo. package br.com.linu.forum.view.util; import java.io.serializable; import java.util.iterator; import javax.faces.facesexception; import javax.faces.event.abortprocessingexception; import javax.faces.event.exceptionqueuedevent; import javax.faces.event.exceptionqueuedeventcontext; import org.apache.commons.lang.exception.exceptionutils; import com.sun.faces.context.exceptionhandlerimpl; public class ExceptionHandlerForum extends ExceptionHandlerImpl implements Serializable { private static final long serialversionuid = public void handle() throws FacesException { Iterator<ExceptionQueuedEvent> iterator = getunhandledexceptionqueuedevents().iterator(); while (iterator.hasnext()) { ExceptionQueuedEvent event = iterator.next(); ExceptionQueuedEventContext context = (ExceptionQueuedEventContext) event.getsource(); if ( context.getexception() instanceof AbortProcessingException ) { /* * Utilização do ExceptionUtils do Apache Commons */ String message = ExceptionUtils.getRootCauseMessage( context.getexception() ); ViewUtilities.sendMessage( message ); super.handle(); Veja que esta classe herda uma ExceptionHandlerImpl criada no Java EE para facilitar a vida daqueles malucos (como nós) que querem implementar sua própria Exception Handler. O único método que precisamos sobrescrever é o handle(). Nesse método, obtemos a fila de exceções (de outro método interno). Em seguida, vasculhamos cada exceção a procura da AbortProcessingException. Essa exceção será disparada quando outra exceção qualquer é obtida do Session Bean gerenciado pelo container. Isso significa que nossa BusinessException, quando ocorrer, será a causa inicial da AbortProcessingException. Deixei claro o momento em que a Apache Commons foi utilizada. Com ela obtemos a causa inicial da exceção (uma BusinessException). Por fim, através de um dos métodos disponíveis em nossa ViewUtilities enviamos uma mensagem para as páginas XHTML - que serão automaticamente exibidas pelo componente <h:messages />. Já temos nossa Handler. Precisamos agora criar a fábrica. Dentro do pacote br.com.linu.forum.view.util crie uma classe chamada ExceptionHandlerForumFactory. package br.com.linu.forum.view.util; import java.io.serializable; import javax.faces.context.exceptionhandler; import javax.faces.context.exceptionhandlerfactory; public class ExceptionHandlerForumFactory extends ExceptionHandlerFactory implements Serializable { private static final long serialversionuid = 1L;

11 @Override public ExceptionHandler getexceptionhandler() { return new ExceptionHandlerForum(); Veja que nada de avançado existe aqui. Apenas tenha o cuidado de estender a classe ExceptionHandlerFactory e sobrescrever o método getexceptionhandler() - retornando nossa própria handler, é claro. Pronto! Todas as classes necessárias foram programadas. Vamos agora configurar o container para trabalhar com a fábrica criada. Para isso, será necessário criar o arquivo faces-config.xml. Clique com o botão direito sobre o diretório SuperForumWeb/WebContent/WEB-INF, selecione a opção New, Other... Dentro da pasta XML, selecione o tipo de arquivo XML e clique em Next

12 Defina o valor de File name como faces-config.xml e clique em Next

13 Selecione a opção Create XML file from an XML schema file e clique em Next

14 Selecione a opção Select XML Catalog entry e selecione o catálogo marcado com a key /xml/ns/javaee/web-facesconfig_2_0.xsd. Em seguida, clique em Next

15 Nessa próxima janela, apenas clique em Finish Pronto! O arquivo de configuração foi criado. Abra-o e deixo com o código igual ao modelo abaixo: <?xml version="1.0" encoding="utf-8"?> <javaee:faces-config version="2.0" xmlns:javaee=" xmlns:xml=" xmlns:xsi=" xsi:schemalocation=" /web-facesconfig_2_0.xsd "> <javaee:factory> <javaee:exception-handler-factory> br.com.linu.forum.view.util.exceptionhandlerforumfactory </javaee:exception-handler-factory> </javaee:factory> </javaee:faces-config> Apenas atente-se que a versão do faces-config agora é sinalizada como 2.0. Só precisamos acrescentar a sintaxe indicativa da fábrica de Exception Hanlder utilizada. Salve e feche o arquivo. Enfim, agora nossa aplicação estará apta a capturar BusinessExceptions e enviá-las para as páginas XHTML que serão criadas. Configurando o arquivo web.xml O arquivo web.xml, muito comum para desenvolvedores de aplicações Web em Java, foi criado pelo Eclipse no diretório SuperForumWeb/WebContent/WEB-INF. Altere seu conteúdo para que fique igual ao código abaixo. <?xml version="1.0" encoding="utf-8"?> <web-app version="3.0" xmlns=" xmlns:xsi=" /2001/XMLSchema-instance" xsi:schemalocation=" /xml/ns/javaee/web-app_3_0.xsd"> <context-param> <param-name>javax.faces.project_stage</param-name> <param-value>development</param-value> </context-param> <servlet> <servlet-name>faces Servlet</servlet-name>

16 <servlet-class>javax.faces.webapp.facesservlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>faces Servlet</servlet-name> <url-pattern>/faces/*</url-pattern> </servlet-mapping> <session-config> <session-timeout> 30 </session-timeout> </session-config> <welcome-file-list> <welcome-file>faces/index.xhtml</welcome-file> </welcome-file-list> </web-app> Aqui também existem novos recursos. Através da tag <context-param> estamos definindo em que período a aplicação se encontra. Neste caso ela está em período de Development (desenvolvimento). Esse tipo de definição trás diferentes comportamentos para a aplicação (como maior ênfase aos LOGs, maior performance para ambiente de produção, etc). As outras configurações tratam do load do FacesServlet e de onde os páginas Faces estarão disponíveis (/faces/*). Com exceção dos elementos de contexto, os outros recursos já eram comuns no arquivo web.xml da versão antiga do Java EE. Você pode verificar mais detalhes sobre a criação desse arquivo (como também de todos os recursos do JSF 2) no excelente material disponibilizado por Edson Gonçalves em na-pratica-parte-1/ Criando o arquivo de folha de estilo padrão Vamos agora criar o CSS das páginas. Para maiores detalhes de como construir documentos web formatados pelo CSS, veja o excelente material disponibilizado em pelo amigável Maurício Samy (em português, é o melhor site de CSS - na minha opinião). Criaremos uma pasta própria (chamada util) para guardar os recursos utilizados pela camada de apresentação. Clique com o botão direito sobre a pasta WebContent do projeto SuperForumWeb, selecione a opção New, opção Folder. Chame a pasta de util. Clique com o botão direito sobre a pasta util, selecione a opção New, Other... Dentro da pasta Web, selecione CSS e clique em Next

17 Defina o valor de File name como style.css e clique em Finish Codifique (leia-se cole) o texto abaixo dentro de seu "iso "; /* CSS Geral */ body { font-family: Verdana, Arial, Sans-serif; font-size: 10px; img { border: 0px; a { font-family: Verdana, Arial, Sans-serif; text-decoration: none; color: green; font-size: 10px; a:hover { text-decoration: underline; div.bottom { width: 100%; text-align: center; div.message { font-size: 10px; text-align: left; color: #660;

18 width: 602px; padding: 8px; margin: 8px; font-weight: bold; text-indent: 5px; /* CSS Geral */ /* CSS para tabelas */ table { border: 1px solid gray; padding: 2px; margin: 8px; width: 618px; table td { background-color: #e5efe5; text-align: center; padding: 4px; table td.describe { text-align: left; width: 350px; table td.normal { table td.comment { text-align: left; table th { background-color: #c5cfc5; padding: 4px; table th.topic { text-align: left; font-weight: normal; font.date { font-weight: bold; color: green; div.topic { border: 1px solid gray; padding: 8px; margin: 8px; background-color: #c5cfc5; width: 600px; height: 85px; font.username { font-weight: bold; /* CSS para tabelas */ /* CSS para formulários */ br { clear: left; label { float: left; width: 120px; text-align: right; margin-top: 5px;

19 input,textarea { width: 300px; margin-bottom: 5px; float: left; textarea { width: 440px; height: 150px; textarea.comment { width: 590px; height: 50px; background-color: #f5f5f5;.submit { margin-left: 120px; margin-top: 5px; width: 90px;.searchButton { width: 90px; margin-left: 5px; h1 { font-size: 12px; color: green; width: 602px; background-color: #c5cfc5; padding: 8px; margin: 8px; div.form { border: 1px solid gray; padding: 8px; margin: 8px; background-color: #e5efe5; width: 600px; /* CSS para formulários */ Esse será nosso padrão CSS para o SuperForum. Parto do princípio que o leitor conheça programação HTML, por isso não entrarei em detalhes sobre a sintaxe do código CSS mostrado. Em caso de dúvidas, veja o já comentado Utilizei também os conceitos de Tableless para construir os formulários. Um simples exemplo, que inclusive foi utilizado para a montagem desse layout, pode ser encontrado em Realizei testes satisfatórios desse CSS nos navegadores Firefox 3, Internet Explorer 8 e Google Chrome. Ahhh. Mais um detalhe: lembra-se daquela imagem do SuperFórum que foi mostrada na parte 1 desse material? Pois é, vamos precisar dela aqui também. Por conveniência, preferi mostrá-la novamente: Baixe para seu computador com o nome logo.png e a salve dentro da pasta SuperForumWeb/WebContent/util (a pasta que criamos anteriormente). Bom, já temos nosso CSS e a imagem do sistema. Vamos agora criar o template das páginas XHTML do Facelets. Criando o arquivo template.xhtml Conforme vimos, o Java EE 6 adota o Facelets como padrão para a camada de apresentação. Os Facelets permitem a construção de templates. Criaremos então um template com o layout padrão das páginas XHTML. O Eclipse, por default, ainda não está respirando os padrões do Facelets. Portanto precisaremos criar nossos arquivos XHTML de forma manual.

20 Clique com o botão direito sobre o diretório util (dentro de WebContent) do projeto SuperForumWeb, selecione a opção New, File Defina File name com o nome template.xhtml e clique em Finish. Copie o código abaixo para o arquivo criado. <?xml version='1.0' encoding='iso '?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " /DTD/xhtml1-transitional.dtd"> <html xmlns=" xmlns:h=" xmlns:f=" xmlns:ui=" <h:head> <meta http-equiv="content-type" content="text/html; charset=iso " /> <link rel="stylesheet" type="text/css" href="util/style.css" /> <title><ui:insert name="title">superfórum</ui:insert></title> </h:head> <h:body> <ui:insert name="header"> <hr /> <img src="util/logo.png" /> <hr /> [<h:link outcome="index"> Buscar Tópicos </h:link>] - [<h:link outcome="topics"> Cadastrar Tópicos </h:link>] <br /><br /> </ui:insert> <ui:insert name="body"> Definir corpo. </ui:insert> <ui:insert name="message"> <div class="message"> <h:messages showsummary="false" showdetail="true" /> </div>

21 </ui:insert> <ui:insert name="footer"> <br /><hr /> <div class="bottom"> </ui:insert> </h:body> </html> Vamos analisar o código. A taq inicial denota que este, trata-se, de um arquivo XML. A segunda tag (DOCTYPE) indica que estamos trabalhando com um XHTML Transitional (que oferece os mesmos recursos do HTML 4.01 Transitional). Existem os seguintes DOCTYPES: Strict, Transitional e Frameset. O tipo de documento Frameset é o mais flexível. Podemos utilizar marcações para frames, elementos deprecated e estilo (CSS) definido nas próprias tags. O tipo Transitional é parecido com o Frameset, porém restringe o uso de marcações para frames. Pode ser considerado como o caso "mais ou menos" dos três tipos de documentos. O Strict não permite CSS dentro das tags e a utilização de elementos deprecated. Para os padrões sugeridos pela W3C, esse tipo garante totalmente a padronização. Para pessoas como eu, que ainda não são 100% conhecidas do XHTML, recomendo o uso de meio termo (o Transitional). Certamente com o tempo o uso do Strict se tornará, por nossa própria opinião, preferível. Para a criação de um XHTML correto precisamos atentar-se aos padrões comuns já definidos ao XML. As considerações abaixo devem ser observadas: Usar tags em caixa-baixa (letras minúsculas); Sempre utilizar o fechamento de tags, mesmo quando sejam vazias (como por exemplo, a tag <br/>); Aninhamento das tags correto (por exemplo, <div><p> devem ser finalizadas com </p></div> - e não com </div></p>); Os documentos devem possuir boa formatação. Essas são as regras básicas para se construir um XHTML. Para maiores detalhes recomendo a leitura de e Na definição da tag html, nós declaramos as namespaces html, core e facelets utilizadas pela JSF 2.0. Veja também que a definição do CHARSET e do arquivo CSS utilizado foram criadas na tag <h:head>. O template Facelets permite definir elementos padrões para as páginas através da sintaxe <ui:insert>, onde o parâmetro name serve como indicador. Dentro dessas definições colocamos os códigos XHTML e JSF necessários. A partir daí, por default, todas as páginas XHTML que fizerem referência a esse template terão, automaticamente, esses campos. Observe que criamos o title, o header, o body, um espaço para mensagens (message) e o footer. Bom, fui breve, mas espero ter sido claro em relação à codificação desse template. Você pode tirar outras dúvidas em relação ao uso dos templates através do artigo (procure pelo tutorial Page Templating with Facelets). O que existe de novo, em relação ao JSF 2.0, nessa página? Claro que o uso de template e XHTML, por si só, já é uma inovação. Mas foi também utilizada a nova tag <h:link/>. O JSF 2.0 oferece grandes recursos para a utilização de comunicação via GET. Na versão 1.2, era necessária muita programação para obter um parâmetro enviado via GET. Não existiam também tags JSF puras que forneciam esses recursos. Essa nova versão trouxe as tags <h:button> e <h:link> que possibilitam justamente esse mecanismo. Veja que através dos comandos <h:link outcome="index"> e <h:link outcome="topics"> estamos utilizando essa notação. Aqui, no entanto, não foram passados parâmetros. Estamos apenas indicando o outcome da navegação. Outra inovação é o usa da Navegação Implícita. Na antiga versão, todo outcome declarado nos elementos JSF nas páginas precisa conter uma navegation-rule relacionada. Aqui, quando não existe uma navegation-rule com o nome do outcome (em nosso caso, index e topics), páginas XHTML com o nome declarado serão automaticamente buscadas. Ou seja, não criamos nenhuma regra de navegação. Quando o link oferecido pelo componente <h:link outcome="index"> for utilizado, a página index.xhtml será referenciada automaticamente. Muito boa essa navegação implícita né!? Evita declarações de navegações básicas (e chatas) nos arquivos XML do servidor de aplicação. É isso ai galera, estamos pronto para criar nossas páginas!!! Desenvolvendo os objetos Viewables As vezes o formato dos dados mantidos no modelo não são totalmente apropriados para a exibição na camada de apresentação. Por conta disso, existem recursos variados (inclusive do próprio JSF) para formatação desses dados. Eu, particularmente, prefiro criar componentes intermediários para fabricar a exibição dos valores da forma esperada. Na verdade, esses componentes não passam de Wrappers (um cara que empacota outro objeto ou primitivo - tire suas dúvidas sobre isso em /wiki/primitive_wrapper_class) para as entidades do modelo. Prefiro trabalhar dessa forma para facilitar o acesso aos dados formatados de forma transparente, como se estivéssemos trabalhando com os próprios pojos da camada Model. Tenho o costume de chamar esses elementos de Viewable. Podemos criar wrappers para cada elemento do modelo - caso haja necessidade. Nesta aplicação nós vamos criar dois wrappers: CommentViewable e TopicViewable. Nesse caso, a entidade Metadata não precisa desse encapsulamento, pois não será exibida explicitamente para os usuários.

22 Crie um pacote no projeto SuperForumWeb chamado br.com.linu.forum.view.viewable. Crie então uma classe chamada TopicViewable. Veja seu código abaixo. package br.com.linu.forum.view.viewable; import java.io.serializable; import br.com.linu.forum.model.topic; import br.com.linu.forum.view.util.viewutilities; public class TopicViewable implements Serializable { private static final long serialversionuid = 1L; private Topic topic; private int countcomments; public TopicViewable(Topic topic, int countcomments) { this.topic = topic; this.countcomments = countcomments; public int getcountcomments() { return this.countcomments; public String getcreationdateformated() { return ViewUtilities.formatDate( this.topic.getcreationdate() ); public Topic gettopic() { return this.topic; Não existe complexidade nesse código. Existem duas propriedades manipuladas por esse objeto: a creationdate e o número de comentários do tópico. O banco de dados guardará em creationdate um Timestamp com a hora da criação do registro. Caso não haja controle de intercionalização, um valor sob o Locale "en" seria exibido. No SuperFórum, porém, precisamos apenas exibir a data de criação. O método getcreationdateformated() foi criado justamente para isso: ele obtém a data da entidade Topic e, através de ViewUtilities.formatDate(), converte para o formato necessário. Sobre o campo countcomments, vale ressaltar que nosso modelo (por opção) não contempla uma associação bidirecional entre Topic e Comment. Isso significa que não temos forma de acessar diretamente um elemento que identifique a quantidade de comentários relacionados aos tópicos (através da chamada do método size() de uma List, por exemplo, seria possível). Dessa forma, criamos aqui um atributo responsável por guardar esse quantitativo. Dessa forma, sempre que um TopicViewable for criado, precisaremos informar (além do Topic encapsulado) a quantidade de comentários associados. Isso será feito em outra classe, quando necessário. Pronto! Dessa forma, todos os dados do tópico necessários para a camada de apresentação estão disponíveis e formatados nessa classe. Vamos fazer o mesmo para Comment. Crie agora uma classe CommentViewable no pacote br.com.linu.forum.view.viewable com o código abaixo. package br.com.linu.forum.view.viewable; import java.io.serializable; import br.com.linu.forum.model.comment; import br.com.linu.forum.view.util.viewutilities; public class CommentViewable implements Serializable { private static final long serialversionuid = 1L; private Comment comment; public CommentViewable(Comment comment) { this.comment = comment; public String getcreationdateformated() { return ViewUtilities.formatDate( this.comment.getcreationdate() );

23 public Comment getcomment() { return this.comment; Esse Wrapper é mais simples. Ele só possui o método para formatação da data de criação. Assim como o anterior, seu construtor precisa receber o objeto encapsulado - neste caso, um Comment. Esses objetos serão intermediários aos elementos do modelo. As classes associadas aos XHTML trabalharão com eles quando isso se fizer necessário. Vamos agora para as últimas classes do nosso sistema! Desenvolvendo a camada de apresentação Optei em construir um Bean para cada página! Isso não é uma regra. Pode haver vários Beans para uma página, como também várias páginas para um único Bean. Cada caso é um caso (poético isso né?!). Vamos lá! Primeiro precisamos descobrir quais páginas vão existir em nosso sistema. Serão necessárias três páginas: a página inicial, que apresentará a listagem de tópicos e possibilitará a consulta através do mecanismo de busca; a página de visualização dos tópicos e seus comentários; e a página de cadastro de tópicos. Portanto vamos criar os arquivos index.xhtml, comments.xhtml e topics.xhtml para atender as páginas citadas acima, respectivamente. Observação: Nos procedimentos anteriores, nós criamos dois pacotes (viewable e util) dentro do prefixo br.com.linu.forum.view. As classes definidas a seguir devem pertencer ao pacote br.com.linu.forum.view, ou seja, ao prefixo já definido desses pacotes. Iniciaremos pela classe de criação de tópicos. Crie uma classe chamada TopicView no pacote br.com.linu.forum.view e codifique o conteúdo abaixo. package br.com.linu.forum.view; import java.io.serializable; import javax.annotation.postconstruct; import javax.ejb.ejb; import javax.faces.bean.managedbean; import javax.faces.bean.requestscoped; import javax.faces.event.actionevent; import br.com.linu.forum.business.businessexception; import br.com.linu.forum.model.topic; public class TopicView implements Serializable { private static final long serialversionuid = private ServiceFacade facade; private Topic public void construct() { this.topic = new Topic(); topic.settitle("novo Tópico"); public Topic gettopic() { return this.topic; public void create(actionevent event) { try { facade.gettopicservice().createtopic(this.topic); catch (BusinessException e) { /* Nada precisa ser feito aqui */

24 Presenciamos aqui várias novidades do JSF 2.0. Observe que essa classe será considerada como um bean gerenciado apenas por conter a Conforme vimos, a última versão do JSF nos obrigava a declarar esse tipo de comportamento através do faces-config.xml. Quando anotamos uma classe e não especificamos explicitamente um escopo, ela será definida no escopo de requisição (Request). Aqui, porém, preferi colocar explicitamente a para indicar essa configuração. Como sabemos, o escopo de requisição fará com que o objeto seja criado apenas para a requisição do momento. Ou seja, a classe basicamente recebe uma instância, executa seus procedimentos, devolve o resultado para a página e depois é destruída - existem mais comportamentos dentro do servidor de aplicação, mas aqui, não nos aprofundaremos nesse sentido. Note que obtemos o SessionBean ServiceFacade através da Através dele teremos acesso ao serviço createtopic() disponível no TopicService. Existe também o detalhe de que alguns procedimentos precisam ser realizados logo após a criação desse objeto. Esses procedimentos são declarados num método anotado (que aqui, por acaso, é chamado de construct() - nome que não é obrigatório). No método create(), o procedimento de criação do tópico será realizado. Veja que não precisamos repassar a mensagem obtida de uma possível exceção para a página XHTML - pois caso ocorra uma BusinessException, nosso Exception Handler construído dará conta do recado. Vamos agora criar a página XHTML associada a esse Managed Bean. Clique com o botão direito sobre a pasta WebContent do projeto SuperForumWeb, selecione a opção New, Other... Selecione a opção General, item File e clique em Next

25 Como a pasta WebContent já está selecionada, precisamos apenas definir o nome do arquivo em File name. Digite topics.xhtml e clique em Finish Digite o conteúdo abaixo no arquivo criado. <?xml version='1.0' encoding='iso '?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " /DTD/xhtml1-transitional.dtd"> <html xmlns=" xmlns:h=" xmlns:f=" xmlns:ui=" <ui:composition template="util/template.xhtml"> <ui:define name="body"> <h1>cadastrar Tópicos</h1> <div class="form"> <h:form> <label> Título: </label> <h:inputtext value="#{topicview.topic.title" /><br /> <label> Usuário: </label> <h:inputtext value="#{topicview.topic.username" /> <br /> <label> Tópico: </label> <h:inputtextarea value="#{topicview.topic.text" /><br /> <h:commandbutton action="index" actionlistener="#{topicview.create" styleclass="submit" value="postar"/> <br /> </h:form> </div> </ui:define> </ui:composition> </html> Note que através dos recursos disponíveis no Facelets, o código da página ficou bem reduzido. A única área que precisamos redefinir é a body. Isso pode ser realizado através da <ui:define name="body">. Observe também que foi necessário (através da <ui:composition>) definir o template Facelets utilizado - nós usamos

26 o template.xhtml criado anteriormente. Só pelo fato da classe TopicView ter sido anotada nós já somos capazes de acessá-la via EL. Como nenhum nome foi definido, ela estará disponível pelo seu próprio nome - com a primeira letra minúscula. Ou seja, quando chamamos o valor #{topicview.topic.title estamos justamente acessando o método gettopic() e, em seguida, o método gettitle(). Tenho como premissa o fato de que o leitor já conheça esse padrão de comportamento de acesso. Caso haja dúvidas, recomendo a leitura do artigo Todos os dados associados às propriedades do bean Topic serão enviados para o servidor no momento em que o botão Postar for acionado. Neste caso, deve-se ter em mente o ciclo de vida natural dos JSF. Veja abaixo uma figura (retirada e adaptada de que representa esse comportamento. Quando uma requisição é identificada, a classe em questão é instanciada. Em seguida ela recebe os valores da requisição. Caso existam validações definidas pela JSF, elas serão aplicadas. Em nosso caso, lembre-se que existem as para alguns campos da classe Topic do modelo. Como essa classe está sendo diretamente acessada através do método gettopic(), caso algum valor definido nos <h:inputtext> ou <h:inputtextarea> esteja inválido, a mensagem (também definida na própria classe do modelo através do atributo message) será enviada para a página XHTML é exibida no <h:messages>. Neste caso, os demais procedimentos não seriam realizados. Caso não haja erros na validação (ou conversão de valores - que em nosso estudo, não foi aplicada), o objeto do modelo será, enfim, atualizado. Nesse momento, a instância de Topic (que foi criada - já comentado) já possui os valores digitados pelo usuário nos campos da página. Em seguida, os Listeners associados aos componentes da tela (em nosso caso, apenas ao botão) serão acionados. O código da página topics.xhtml associa ao <h:commandbutton> o comportamento definido no método create() da classe TopicView através do parâmetro actionlistener="# {topicview.create". Para o leitor familiarizado com o comportamento padrão do JSF 1.2, esse ciclo de vida é conhecido. Para uma total abordagem sobre os conceitos inerentes ao comportamento dos componentes JSF, seu ciclo de vida, maiores detalhes sobre validações, conversões e eventos, recomendo a leitura completa do material disponibilizado em - de onde, inclusive, a figura ao lado foi adaptada. Só para constar, devemos nos lembrar que, quando o método createtopic() de TopicService é chamado dentro do método create(), um procedimento de validação padrão para os tópicos (definido no método polimórfico validate()) é acionado. Dessa forma, todas as outras regras de negócio (como por exemplo, o fato de que o título do tópico deve ser único) serão validadas. Isso fará com que somente os tópicos totalmente íntegros sejam passados para a camada de persistência e, consequentemente, salvos no banco de dados. Veja ainda que através do action="index" do componente <h:commandbutton> estamos utilizando o recurso de navegação implícita. Neste caso, se todas as atividades referente à gravação de dados ocorrerem com sucesso, o usuário será redirecionado para a página index.xhtml. Vamos criar agora os componentes associados a essa página. Crie uma classe chamada SearchView no pacote br.com.linu.forum.view. package br.com.linu.forum.view; import java.io.serializable; import java.util.arraylist; import java.util.list; import javax.annotation.postconstruct; import javax.annotation.predestroy; import javax.ejb.ejb; import javax.faces.bean.managedbean; import javax.faces.bean.viewscoped; import javax.faces.event.actionevent; import br.com.linu.forum.business.businessexception; import br.com.linu.forum.model.topic; import br.com.linu.forum.services.servicefacade;

27 import br.com.linu.forum.view.util.viewutilities; public class SearchView implements Serializable { private static final long serialversionuid = private ServiceFacade facade; private List<TopicViewable> topics; private String word; public void setword(string word) { this.word = word.trim(); public String getword() { return word; public List<TopicViewable> gettopics() { return this.topics; private void search() { try { if ( this.getword().equals("") ) topics = this.convert( facade.gettopicservice().gettopics() ); else topics = this.convert( facade.gettopicservice().searchtopics( this.getword() ) ); if ( this.topics.size() == 0 ) throw new BusinessException( "Nenhum tópico foi encontrado." ); catch (BusinessException ex) { ViewUtilities.sendMessage( ex.getmessage() ); public void search(actionevent e) { this.search(); public boolean isemptylist() { return this.topics.isempty(); private int getcountcomments(topic topic) throws BusinessException { return this.facade.getcommentservice().getcomments(topic).size(); private List<TopicViewable> convert(list<topic> topics) throws BusinessException { List<TopicViewable> viewables = new ArrayList<TopicViewable>(); for (Topic topic : topics) { int count = this.getcountcomments(topic); viewables.add( new TopicViewable(topic,count) ); return public void construct() { this.setword(""); public void destroy() { topics = null; Essa classe também será publicada para as páginas XHTML através da porém, aqui estamos definindo um outro tipo de Esse é um novo tipo de escopo disponível no JSF 2.0. Ele trás um intermédio entre os escopos de requisição e sessão (já conhecidos no desenvolvimento de sistemas web). Como sabemos, o escopo de requisição cria o objeto somente para a

28 chamada do usuário, não mantendo quaisquer estados entre duas requisições. O escopo de sessão, entretanto, é capaz de manter os dados do usuário entre várias chamadas, se mantendo ativo durante o período em que o usuário estiver trabalhando com esta sessão. Ele será fechado somente quando o usuário fechar a sessão ou o tempo previsto terminar. Esse novo escopo, disponível é capaz de manter os dados da requisição até o momento em que uma nova página é chamada. Em outras palavras, em quanto o usuário estiver apontando para esse bean e enquanto nenhum outcome for executado, o escopo estará disponível. Essa nova atração favorece a criação de páginas onde é necessário se manter um estado de conversação entre algumas requisições, sem que esses dados se mantenham ativos por todo o tempo de vida da sessão. Outro detalhe importante se refere ao fato de que as só serão chamadas uma vez, durante todo o tempo de vida do bean - diferente do comportamento de - em que esses comportamentos seriam executados em todas as requisições ao bean. Essa classe SearchView que estamos criando, por exemplo, é um típico caso de onde seria interessante utilizar Note que sempre que esse bean for publicado, o método construct() será executado. Nesse método, definimos como padrão a String "" para o atributo word. Esse atributo guarda a palavra que o usuário deseja pesquisar. Ao definirmos "", estamos indicando que não existe palavra a ser pesquisada. Ainda neste método, temos uma chamada ao método polimórfico privado search() (sem o parâmetro ActionEvent). Esse método guarda uma listagem de tópicos (encapsulados na nossa Wrapper TopicViewable) no atributo topics de acordo com o valor de word. Se word for vazia (""), uma lista de todos os tópicos do sistema será obtida através do método gettopics() de TopicService. Caso word não esteja vazia, a listagem será obtida através do método searchtopics(). Ambos os métodos estão disponíveis através da ServiceFacade resgatada do projeto SuperForumEJB. A condição seguinte verifica a listagem e, caso size() seja igual a 0 (ou seja, não existem elementos), dispara uma BusinessException que será exibida na página XHTML. Veja que para popular o atributo topics, é usado o método privado convert() que converte uma listagem de tópicos em TopicViewable. Esse método ainda utiliza o método getcountcomments() para os tópicos. Esse recurso é usado para instanciar um TopicViewable - que, conforme vimos, necessita tanto do tópico quanto da quantidade de comentários a ele associados. Esse objeto sempre guardará uma listagem de tópicos (inteira ou limitada através da word). Essa listagem está disponível para a página através do gettopics(). Existem também o Getter e Setter para o atributo word. Dessa forma, podemos construir nossa página XHTML. Crie um novo arquivo XHTML (conforme procedimento já mostrado) no diretório SuperForumWeb/WebContent chamado index.xhtml. O código desse arquivo é mostrado abaixo. <?xml version='1.0' encoding='iso '?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " /DTD/xhtml1-transitional.dtd"> <html xmlns=" xmlns:h=" xmlns:f=" xmlns:ui=" <ui:composition template="util/template.xhtml"> <ui:define name="body"> <f:view> <h:form> <div class="form"><label> Digite uma palavra: </label> <h:inputtext value="#{searchview.word" /> <h:commandbutton actionlistener="#{searchview.search" styleclass="searchbutton" value="pesquisar"/> <br /> </div> <h:datatable value="#{searchview.topics" var="item" rendered="#{!searchview.emptylist" columnclasses="describe,normal,normal"> <h:column> <f:facet name="header"> <h:outputtext value="tópico" /> </f:facet> <h:link outcome="comments"> <f:param name="topic" value="#{item.topic.id"/> <h:outputtext value="#{item.topic.title" /> </h:link> </h:column> <h:column> <f:facet name="header"> <h:outputtext value="comentários" /> </f:facet> <h:outputtext value="#{item.countcomments" /> </h:column> <h:column> <f:facet name="header">

29 <h:outputtext value="postagem" /> </f:facet> <h:outputtext value="#{item.creationdateformated" /> </h:column> </h:datatable> </h:form> </f:view> </ui:define> </ui:composition> </html> Veremos os detalhes de sua implementação agora. Tudo que nos interessa está compreendido entre as tags <h:form> e </h:form>. A primeira <div> define o formulário para que o usuário digite uma palavra a ser pesquisada. Repare que o único <h:inputtext> contido nesse item está ligado ao atributo word de SearchView. O <h:commandbutton> possui sua actionlistener apontando para o método search() assinada com ActionEvent. Ou seja, quando esse botão for pressionado, o valor digitado pelo usuário será enviado para word e em seguida, o método search() atualizará a listagem de tópicos. Observe que não foi definida uma action para o <h:commandbutton>. Lembre-se que, mesmo que apontássemos a action para o mesmo bean gerenciado (no caso, SearchView), o seria finalizado - é finalizado quando um outcome é acionado. Por isso omitimos o recurso de redirecionamento do botão para que nosso escopo view fosse mantido. A exibição dos tópicos está concentrada na <h:datatable>. Veja que ela só será exibida se a negação do retorno de isemptylist() for verdadeira. Esse método retorna true se a lista de tópicos for vazia. Então, se for vazia, a tabela não será exibida. Os elementos serão exibidos na tabela através de <h:column> e <h:outputtext>, como já fazíamos nas páginas JSP do antigo JSF 1.2. Porém, existe aqui um novo elemento a ser considerado: <h:link>. Conforme vimos, a nova versão da JSF trouxe vários recursos de requisições via GET. Esse componente faz exatamente isso. Ele é capaz de realizar um redirecionamento (pela navegação implícita definida no outcome) para a página comments.xhtml passando um parâmetro, definido no elemento <f:param> na URL. Ou seja, supondo que o usuário clique no link correspondente ao tópico de código 5, o navegador será redirecionado para a página - levando em consideração que a aplicação esteja rodando em localhost. Certamente a página destino será construída de forma apropriada para receber esse parâmetro via URL. O grande avanço nesse recurso gira em torno da possibilidade que o usuário do sistema tem de guardar essa página nos favoritos, ou seja, é uma página Bookmarkable. Vamos agora a nossa última página. Crie uma classe chamada CommentView no pacote br.com.linu.forum.view. Seu código é mostrado abaixo. package br.com.linu.forum.view; import java.io.serializable; import java.util.arraylist; import java.util.list; import javax.annotation.postconstruct; import javax.ejb.ejb; import javax.faces.bean.managedbean; import javax.faces.bean.sessionscoped; import javax.faces.event.actionevent; import br.com.linu.forum.business.businessexception; import br.com.linu.forum.model.comment; import br.com.linu.forum.model.topic; import br.com.linu.forum.services.servicefacade; import br.com.linu.forum.view.util.viewutilities; import br.com.linu.forum.view.viewable.commentviewable; public class CommentView implements Serializable { private static final long serialversionuid = private ServiceFacade facade; private String topicid; private Comment comment; private List<CommentViewable> comments; private TopicViewable topicviewable;