FRAMEWORKS PARA O DESENVOLVIMENTO WEB

Transcrição

1 Guilherme Augusto Peron Borges Semestre FRAMEWORKS PARA O DESENVOLVIMENTO WEB Jaguariúna 2007

2 Guilherme Augusto Peron Borges Semestre FRAMEWORKS PARA O DESENVOLVIMENTO WEB Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do curso de Ciência da Computação da Faculdade de Jaguariúna, sob orientação do Prof. Ms. Peter Jandl Jr., como exigência parcial para conclusão do curso de graduação. Jaguariúna 2007

3 BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web. Monografia defendida e aprovada na FAJ em 13 de dezembro de 2007 pela banca examinadora constituída pelos professores: Prof. Ms. Peter Jandl Jr. FAJ - Orientador Prof. Ms. Ricardo Menezes Salgado FAJ Prof. Ms. Christiane Nova Barbato FAJ

4 AGRADECIMENTOS Agradeço aos meus pais por terem me apoiado durante todo o curso e em minhas decisões. Agradeço também ao meu professor orientador, Peter Jandl Jr., pela grande ajuda durante todo o processo de desenvolvimento deste trabalho, na elaboração da monografia, na seleção dos frameworks que seriam utilizados e também na parte prática, onde foi realizado o desenvolvimento de dois protótipos de aplicação web.

5 BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web Monografia (Bacharelado em Ciência da Computação) Curso de Ciência da Computação da Faculdade de Jaguariúna, Jaguariúna. RESUMO Uma área que já é de extrema importância para a sociedade atual, e que esta aumentando dia a dia, devido à facilidade e flexibilidade que proporciona a seus usuários, é a internet. Devido aos benefícios que esta oferece, aplicações são desenvolvidas para que possam ser acessadas de qualquer lugar, não ficando restrito ao ambiente de instalação. Para facilitar a construção das aplicações web, são utilizados frameworks específicos. Foi realizado um estudo comparativo de dois frameworks baseados em componente para o desenvolvimento web, o JSF e o Tapestry, ambos utilizando a tecnologia Java (que é amplamente utilizada no mercado atual). Como a tecnologia utilizada em comum nos frameworks é o Java, foi feito um estudo de como são construídas as aplicações web utilizando o Java, sem nenhum framework específico, ou seja, como funciona o JEE, que é uma API que o Java disponibiliza, sendo principalmente utilizada no desenvolvimento de aplicações web, um dos principais artefatos que o JEE possui, se tratando de aplicações web, são os servlets que são responsáveis pelo controle de requisições web que as aplicações geram e conseqüentemente é essencial para a construção das aplicações web que utilizam o Java, portanto foi realizado um estudo das funcionalidades básicas que os servlets possuem e como estas são utilizadas, já que implicitamente os frameworks utilizados no trabalho utilizam o JEE e conseqüentemente utilizam os servlets. Também foram tratados especificamente os frameworks JSF e Tapestry, explicando suas principais funcionalidades, foi desenvolvido um componente simples em ambos os frameworks com eventuais exemplos. Dois protótipos de aplicação web possuindo as mesmas funcionalidades e aparências foram desenvolvidos com ambos os frameworks. Com o conhecimento obtido na teoria dos estudos e na prática com o desenvolvimento dos protótipos, foi realizado um estudo comparativo entre os dois frameworks utilizados no desenvolvimento. Neste trabalho foram utilizados somente dois de muitos framewoks web baseados em componentes disponíveis no mercado, mas através destes é possível obter um conhecimento de como, no geral, são desenvolvidas e como funcionam as aplicações web e ter uma visão mais ampla deste paradigma de programação de aplicações web. Palavras-chave: FRAMEWORK, JEE, SERVLET, JSF, TAPESTRY.

6 ABSTRACT An area that is already of extreme importance for the actual society, and that is increasing day by day, due to facility and flexibility that provides for your users, is the internet. Due to the benefits that it offers, applications are developed for being accessed from anywhere, not being restricted to the environment installation. To facilitate the construction of web applications, are used specifics frameworks. A comparative study was realized for two frameworks based on components for web development, the JSF and Tapestry, both using the Java technology (which is widely used in the current market). As the technology used in common on frameworks is Java, a study was made of how the web applications are built using Java, without any specific framework, i.e. how works the JEE, which is a API that Java provides, being principally used in the development of web applications, one of the principals artifacts that JEE has, been dealing of web applications, are the servlets that are responsible for the controlling of the web requests that the web applications generate and therefore it is essential for the construction of the web applications that use Java, so a study was realized of the basic features that servlets have and how they are used, since that implicitly the frameworks used in the work use the JEE and therefore use the servlets. Also was treated specifically the frameworks JSF and Tapestry, explaining their main features, was developed a simple component in both frameworks with some examples. Two prototypes of web application with the same features and appearance were developed with both frameworks. With the knowledge gained in the theoretical studies and in the practice with the development of prototypes, was realized a comparative study between the two frameworks used in the development. In this work were used only two of many web framewoks based on components available on the market, but through these it s possible to get an knowledge of how, in general, are developed and how works the web applications and have a broader view of this paradigm of web applications programming. Key-words: FRAMEWORK, JEE, SERVLET, JSF, TAPESTRY.

7 SUMÁRIO 1. INTRODUÇÃO METODOLOGIA APLICAÇÕES WEB JEE Segurança Componentes Aplicação em JEE Servlet Exemplo de verificação de login em JEE JSF Internacionalização Backing Beans Eventos no JSF Componentes API para desenvolvimento de componentes gráficos no JSF TAPESTRY Estrutura Ciclo de processos no Tapestry Componentes no Tapestry Exemplo de criação de componente DESCRIÇÃO DO PROTÓTIPO Descrição do ambiente de teste e desenvolvimento Desenvolvimento do Protótipo utilizando o JSF Desenvolvimento do Protótipo utilizando o Tapestry COMPARAÇÃO JSF X TAPESTRY Praticidade Complexidade do ambiente necessário para a utilização do framework Quantidade de componentes nativos disponíveis para utilização Quantidade de componentes de terceiros disponíveis para o framework Ferramentas disponíveis para a utilização do framework Utilização do framework no mercado atual Atualizações dos frameworks na atualidade...66

8 9. CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS...69

9 Lista de Figuras Figura Ilustação do fluxo de aplicações web...4 Figura Ilustração de dois sistemas JEE multicamadas...6 Figura Fluxo de sistemas JEE...8 Figura Nível de abstração de tecnologias utilizadas no JSF...17 Figura Conteúdo do componente gerado no browser do cliente...32 Figura Estrutura básica de uma aplicação Tapestry em um servidor de aplicações...34 Figura Estrutura de execução de componentes no Tapestry...40 Figura UML com as classes para a criação de componentes no Tapestry...43 Figura Conteúdo do componente gerado no browser do cliente...45 Figura Tela de login do protótipo desenvolvido em JSF...48 Figura Menu do protótipo desenvolvido em JSF...49 Figura Tela de filtro de funcionário...49 Figura Tela de dados do funcionário...50 Figura Tela de filtro do funcionário que será alterado...50 Figura Tela de alteração do funcionário...51 Figura Mensagem de alerta para o usuário, referente ao preenchimento dos campos..51 Figura Mensagem de alerta para o usuário, referente ao formato dos campos...51 Figura Tela de cadastro...52 Figura Tela de exclusão de funcionários...52 Figura Página informando que o funcionário requisitado não existe no sistema...53 Figura Página informando que a operação ocorreu com sucesso...53 Figura Página informando que a operação não foi realizada por algum erro...54 Figura Tela de login do protótipo desenvolvido em Tapestry...54 Figura Menu do protótipo desenvolvido em Tapestry...55 Figura Tela de filtro de funcionário...55 Figura Tela de dados do funcionário...56 Figura Tela de filtro do funcionário que será alterado...56 Figura Tela de alteração do funcionário...57 Figura Mensagem de alerta para o usuário, referente ao preenchimento dos campos..57 Figura Mensagem de alerta para o usuário, referente ao formato dos campos...58 Figura Tela de cadastro...58

10 Figura Tela de exclusão de funcionários...59 Figura Página informando que o funcionário requisitado não existe no sistema...59 Figura Página informando que a operação ocorreu com sucesso...60 Figura Página informando que a operação não foi realizada por algum erro...60

11 Lista de Siglas AJAX - Asynchronous Javascript and XML API - Application Programming Language CSS - Cascading Style Sheets EIS - Enterprise System Information EJB - Enterprise JavaBeans EL - Expression Language HTML - HyperText Markup Language HTTP - HyperText Trasfer Protocol IDE - Integrated Development Environmet JDBC - Java Database Connectivity JEE - Java Enterprise Edition JRE - Java Runtime Environment JSF - JavaServer Faces JSP - JavaServer Pages JVM - Java Virtual Machine RAM - Random Access Memory SDK - Software Development Kit SQL - Structured Query Language TLD - Tag Library Descriptor UML - Unified Modeling Language URI - Uniform Resource Identifier URL - Uniform Resource Locator XML - Extensible Markup Language

12 1 1. INTRODUÇÃO A internet, ou a web, é de extrema importância para a sociedade, sendo uma das principais fontes de informações. De alguns anos para cá, a internet vem crescendo muito e conseqüentemente sendo mais exigida pelos usuários, tanto em hardware quanto em software. Como exemplo da importância da internet na sociedade e a facilidade que a mesma pode trazer, pode-se citar a utilização de sites de comércio, onde uma pessoa pode comprar produtos de várias categorias, sem sair de sua casa ou trabalho, ou sites de bancos onde se pode controlar uma determinada conta bancária ou até sites em que se pagam contas. Conforme Ship (2004), os web sites não permanecem estáticos por muito tempo, ao invés disso, são transformados em aplicações web. Uma aplicação web é interativa, o usuário final irá interagir com links que devem ser clicados, fomulários que devem ser preenchidos e com outras páginas que receberá como resposta, entre outros recursos que uma aplicação web oferece, deixando assim de ser somente um site estático. Dia a dia os usuários de sistemas ou sites na web estão mais exigentes quanto à rapidez, eficácia e qualidade destes sistemas/sites. Portanto para se obter esta qualidade e eficácia em um software, é necessário possuir um bom padrão de trabalho atentando-se aos requisitos funcionais e requisitos físicos. Um exemplo de requisito físico seria um site na web voltado especificamente para um determinado hardware ou sistema operacional, por exemplo, um site que necessariamente tem que ser mantido em um servidor Linux, todo o seu desenvolvimento tem que ser específico para este sistema operacional (no caso o Linux) e isso pode envolver pontos em que não funcione em outros sistemas operacionais, tornando este sistema ou site específico para os clientes que possuem servidor Linux. Muitas vezes o trabalho para o desenvolvimento de um sistema ou site voltado para a web torna-se repetitivo e pouco produtivo, fazendo com que se perca um tempo considerável em tarefas que poderiam ser reutilizadas. Por exemplo, um sistema de cadastro de produtos que terá dez telas, sendo que o padrão para as telas será o mesmo, ou seja, utilizará o mesmo layout, com os mesmos componentes e os mesmos formulários para o cadastro e edição de um determinado produto. Uma boa parte do processo de desenvolvimento deste produto seria utilizada para a criação dos layouts de cada tela e seus respectivos campos e formulários, porém esta tarefa como é repetitiva, poderia ser desenvolvida apenas uma vez e ser reutilizada quando fosse necessário, seria criado apenas um layout, um formulário e um componente de cada tipo que fosse necessário e reutilizado estes mesmos recursos em todas as telas, sem ter que criar especificamente para cada tela todo o layout, alterando-se somente o necessário, como os títulos ou nomes dos campos. Para evitar esse tempo desperdiçado conforme exemplificado, pode-se utilizar um framework para a criação destas telas que terão recursos em comum. Um framework, conforme a tradução para o português, é um molde de trabalho onde elementos em comum no sistema ou no desenvolvimento podem ser reutilizados, evitando assim o desperdício de tempo em algo que pode ser reutilizado. De acordo com Ship (2004), um framework é um conjunto de classes cooperadoras que fazem um padrão reutilizável para uma categoria específica de software. Um framework é diferente de uma ferramenta; uma ferramenta é uma coleção de classes reutilizáveis individuais, cada classe contendo uma pequena e isolada funcionalidade que é aplicável para uma grande variedade de utilidades. Voltando ao exemplo, se para a criação do sistema de cadastro fosse utilizado um framework, todo o trabalho da criação do layout das telas quem faria seria o framework, ao

13 invés de se criar o mesmo layout para cada tela, poderia apenas passar os títulos e nome dos campos dos formulários para o framework e o próprio montaria o layout no padrão desejado com os labels passados. O tempo que se desperdiçaria neste sistema não se restringe somente à criação dos layouts ou componentes para cada tela, mas também em eventuais customizações e manutenções que podem ser necessárias no decorrer da utilização do sistema. Possuindo um bom framework, essas customizações e manutenções muitas vezes podem ser feitas em apenas um lugar do sistema e afetaria todo o sistema, não precisando alterar parte a parte do sistema, portanto ganha-se tempo. Supondo que neste mesmo sistema o cliente quer que o layout tenha alguns pontos alterados, com a utilização do framework, poderia alterar o layout de acordo com o que o cliente deseja em apenas um ponto, pois o layout de todas as telas é construído a partir deste ponto que será alterado, ou seja, o framework será alterado e não tela por tela, sem a utilização deste framework que elabora o layout para o sistema, a alteração que o cliente deseja seria feita em todas as telas do sistema, ou seja, em vários trechos ao invés de apenas um, o que levaria um tempo muito maior. Segundo Lieberman (2007), a modelagem de um software complexo pode ser uma tarefa desafiadora. Padrões de desenho e análise de modelos são úteis, mas geralmente não mostram como aplicar técnicas ou demonstram exemplos de problemas que são similares aos que se desejam em um determinado momento. Felizmente, pode-se utilizar frameworks para coletar e organizar análise de padrões, modelos, ferramentas, técnicas de organização, exemplos e experiência de outros analistas que solucionaram problemas que podem ser similares a um determinado problema que se deseja uma solução confiável. Com a utilização do framework, o desenvolvedor pode utilizar o tempo disponível mais especificamente na camada de negócios do sistema, na parte funcional, o que contribui para uma qualidade maior no sistema e conseqüentemente menos problemas. A utilização de um bom framework traz muitas outras vantagens ao desenvolvedor e algumas dessas outras vantagens serão mostradas neste trabalho que desenvolverá um protótipo de uma aplicação web de cadastro de funcionários de uma determinada empresa, utilizando dois frameworks baseados em componentes para o desenvolvimento web, o JSF (Java Server Faces) (SUN, 2007b) e o Tapestry (ASF, 2007a), ambos utilizando a tecnologia Java (DEITEL, H.; DEITEL, P., 2005; JANDL, 2007). O trabalho terá os seguintes objetivos: estudar a importância de frameworks baseados em componentes para o desenvolvimento web; realizar um estudo comparativo entre dois frameworks baseados em componentes para o desenvolvimento web; desenvolver um sistema simples com os frameworks utilizados no estudo comparativo e apontar quais foram às vantagens e desvantagens entre os frameworks utilizados para o desenvolvimento do sistema. 2

14 3 2. METODOLOGIA O trabalho seguiu uma metodologia tradicional para seu desenvolvimento, sendo dividida em etapas, desde o levantamento bibliográfico até a escrita final da monografia, ficando da seguinte forma: 1- Levantamento bibliográfico (referências referentes à Java e aos frameworks JSF e Tapestry). 2- Estudo do framework Java Server Faces (início dos estudos do framework JSF). 3- Estudo do framework Tapestry (início dos estudos do framework Tapestry). 4- Especificação do protótipo (definição do propósito e das funcionalidades do protótipo). 5- Escrita do relatório parcial. 6- Desenvolvimento do protótipo (desenvolvimento dos dois protótipos, um utilizando JSF e outro utilizando Tapestry). 7- Ajustes (eventuais correções e revisão do material). 8- Análise dos resultados (recolhimento e conclusão dos resultados obtidos). 9- Escrita da monografia (escrita final da monografia).

15 4 3. APLICAÇÕES WEB Basicamente, todo sistema web ou site, possui o seguinte ciclo: é feita uma requisição pelo usuário, essa requisição é enviada para o servidor e o mesmo faz a devida lógica com a requisição recebida, podendo acessar um determinado banco de dados, após a execução da lógica, o servidor retorna uma resposta para o usuário. Exemplificando, um usuário faz seu login em um sistema web através de um browser, após o usuário clicar no botão para ser validado o login, são enviados para o servidor os dados informados pelo usuário. O servidor receberá estes dados e executará a lógica para determinar se o login daquele usuário é válido ou não, enviando assim uma resposta para o browser do usuário, essa resposta pode ser uma nova página redirecionando o sistema, ou uma página informando que o login do usuário é inválido. Conforme a figura 3.1: Figura Ilustação do fluxo de aplicações web Browser: é o navegador para os usuários interagirem com páginas HTML (HyperText Markup Language); a interface entre o usuário e o servidor, indiretamente, pois o usuário apenas tem o trabalho de especificar o que se deseja, e não de enviar os dados para o servidor, essa tarefa quem faz é o próprio browser através do protocolo HTTP (HyperText Trasfer Protocol). Servidor Web: basicamente é um computador que através de um determinado servidor instalado, recebe e envia os dados para o computador cliente (usuário), que conforme a ilustração são as requisições e as respostas (request e response). o Os componentes web que estão contidos no servidor web, são os elementos que são utilizados para o processamento da devida lógica das requisições recebidas. Esses componentes podem ser: Serviços específicos do servidor;

16 5 JSP s (Java Server Pages), que são páginas desenvolvidas e processadas em Java, que resulta no final em uma página HTML para o processamento no browser do usuário; Java Servlets, que basicamente são classes em Java que processa as requisições e constrói as respostas que são enviadas para o browser do computador cliente; Container web, que é responsável pelo controle dos servlets, (neste trabalho de conclusão de curso, será utilizado o container web Tomcat (ASF, 2007b)); Entre outros elementos. Banco de Dados: Onde serão armazenadas e consultadas informações referentes ao sistema, portanto os componentes web podem também fazer o acesso a banco de dados para o armazenamento e consulta de informações, conforme a figura 3.1 (no desenvolvimento dos protótipos foi utilizado o banco de dados MySql (Mysql, 2007)). Os dois frameworks que serão utilizados para o desenvolvimento de um protótipo de um sistema web neste trabalho, que são, o JSF (Java Server Faces) e o Tapestry utilizam a tecnologia Java em sua implementação e mais especificamente utilizam o JEE (Java Enterprise Edition), anteriormente conhecido como J2EE (Java 2 Enterprise Edition), que será mais bem detalhado no próximo capítulo.

17 6 4. JEE O JEE é uma plataforma de programação voltada para aplicações web baseadas em componentes, que são executadas em um servidor. O JEE faz parte da plataforma Java. Através do JEE, pode-se criar sistemas web complexos e contendo portabilidade (pois utiliza a tecnologia Java que é independente de sistema operacional, necessitando apenas a máquina virtual Java (JVM) instalada no sistema operacional), segurança, e uma boa produtividade. No geral o JEE é modelado para o desenvolvimento de aplicações que implementam serviços coorporativos, podendo justificar assim o seu significado (Enterprise Edition), sendo a edição coorporativa do Java para o desenvolvimento web. A plataforma JEE utiliza um modelo de aplicações de multicamadas para aplicações coorporativas sendo que a lógica de aplicação é dividida em componentes de acordo com a sua função. Figura Ilustração de dois sistemas JEE multicamadas (SUN, 2007a) No geral, as aplicações web JEE, são compostas por três camadas dependentes, como ilustra a figura 4.1, as máquinas clientes (camada cliente), o servidor JEE (composto pela camada web e pela camada de negócio) e o banco de dados ou máquinas dependentes (camada de informações) conforme a ilustração. Camadas presentes em aplicações JEE: A camada cliente (cujo termo em inglês é Client Tier), é executada na máquina do cliente, podendo ser o computador de um usuário acessando uma aplicação JEE através de uma aplicação client-server (que seria a aplicação JEE 1) ou através de

18 7 um browser (que seria a aplicação JEE 2) interagindo com páginas HTML dinâmicas. A camada web (que possui o termo em inglês Web Tier), é executada no servidor JEE, esse servidor podendo ser, por exemplo, o Tomcat que foi utilizado neste trabalho para a implementação dos protótipos dos sistemas web. A camada de negócio (cujo termo em inglês é Business Tier), também é executada no servidor JEE, é onde toda a regra funcional do sistema se localiza. A camada de informações (também conhecida pelo termo em inglês EIS (Enterprise System Information) Tier), é executada no servidor de informações, sendo este um servidor de banco de dados. 4.1 Segurança Existem modelos de desenvolvimento de aplicações web coorporativas em que a segurança depende de uma plataforma específica, o que não ocorre no JEE, pois o mesmo possui a portabilidade que o Java proporciona, tornando-se independente de plataforma. O JEE permite o controle de regras de acesso que são definidas pelo desenvolvedor e que são executadas no servidor quando requisitadas. Segundo Sun (2007a), uma mesma aplicação pode ser executada em vários ambientes de segurança sem ter o seu código fonte alterado. 4.2 Componentes O JEE é composto por componentes. Um componente JEE é uma unidade funcional de software reservada que é agregada a uma aplicação JEE que é composta por classes e arquivos que se comunicam com outros componentes. A especificação do JEE define os seguintes componentes: Aplicações clientes e applets que são componentes executados na máquina do cliente (são aplicações que no geral são independentes do que se encontra no servidor). Java Servlets (que será explicado em um tópico posterior), JavaServer Faces (framework baseado em componentes que será utilizado na implementação de um protótipo de sistema web neste trabalho) e JSP (que também será explicado em um tópico posterior) são componentes web que são executados no servidor. EJB (Enterprise JavaBeans) que são componentes voltados principalmente à lógica de negócio e que também são executados no servidor. Todos estes componentes são escritos na linguagem Java e são compilados e interpretados da mesma maneira que qualquer software ou classe desenvolvida em Java seria. As diferenças entre classes Java e estes componentes JEE são que os componentes estão

19 8 integrados em uma aplicação JEE, são desenvolvidos para obter uma melhor performance juntamente com a especificação do JEE, são desenvolvidos para obter uma melhor produtividade e são executados e gerenciados pelo servidor JEE. 4.3 Aplicação em JEE Em um sistema JEE, o fluxo ocorre através da interação entre os elementos do lado cliente e os elementos do lado servidor (estes sendo os componentes da camada web e da camada de negócio, conforme explicado anteriormente). Segue uma ilustração do fluxo que ocorre em sistemas JEE juntamente com sua explicação: Conforme figura 4.3.1: Figura Fluxo de sistemas JEE (SUN, 2007a) 1. A camada cliente envia uma requisição HTTP (HTTP Request) para o servidor web. 2. O servidor web converte esta requisição HTTP em um objeto HTTPServletRequest (que será utilizado em exemplo posteriormente). O objeto HTTPServletRequest é enviado para um componente web. 3. O componente web que recebeu o HTTPServletRequest faz o tratamento da requisição podendo ter acesso à JavaBeans (uma espécie de componente Java simples). 4. E o mesmo componente pode também ter acesso a um banco de dados.

20 9 5. Após o componente web realizar a lógica necessária e gerar conteúdo dinâmico, o componente gera o objeto HTTPServletResponse para retornar a resposta ao cliente, ou repassa a requisição para um outro componente tratá-la. 6. E finalmente o componente web que ficou com o tratamento final da requisição envia o objeto HTTPServletResponse para o servidor web que converte este objeto para uma resposta HTTP (HTTP response) e envia para o cliente. De acordo com Sun (2007a), o processo para criar e executar uma aplicação web é diferente do processo de criação das tradicionais classes Java. O processo para a criação, organização e execução de uma aplicação web pode ser sumarizada da seguinte forma: 1. Desenvolver o código do componente web. 2. Desenvolver o descritor de construção da aplicação web. 3. Compilar os componentes da aplicação e suas classes de ajuda referenciadas pelos componentes. 4. Opcionalmente empacotar a aplicação em uma unidade de construção. 5. Adaptar ou construir a aplicação em um container web (como o Apache Tomcat). 6. Acessar a URL (Uniform Resource Locator) que referencia a aplicação web. 4.4 Servlet Servlets são classes Java que são responsáveis pelo controle das requisições realizadas pela camada cliente do sistema. São executados através do container web, onde são configurados para isto. Uma aplicação JEE padrão é por definição baseada em servlets. As páginas HTML, que são visualizadas pelo browser do usuário, utilizam o protocolo HTTP, que é para conteúdos estáticos, portanto as páginas HTML são geralmente fixas, ou seja, o usuário não consegue uma interação como conseguiria em um sistema desktop, podendo apenas interagir com o conteúdo da página através de cliques em links. Os servlets conseguem retornar uma nova página HTML para o usuário, esta sendo criada dinamicamente de acordo com a lógica implementada no servlet. Conforme Ball et al. (2006), a tecnologia dos Java Servlets permite que seja feita a definição de classes servlets específicas para HTTP. Uma classe servlet estende as capacidades de servidores que mantém aplicações que são acessadas por um modelo de requisição-resposta. Contudo, os servlets podem responder a qualquer tipo de requisição, são geralmente utilizados para estender as aplicações mantidas por servidores web. A requisição do usuário chega até o servidor web sendo uma requisição HTTP, o servidor web converte esta requisição em um objeto do tipo HTTPServletRequest e envia para o servlet que irá interagir com a requisição do cliente através deste objeto recebido. Após realizar a lógica de negócio necessária com a requisição do cliente, o servlet através do objeto HTTPServletResponse gera o conteúdo necessário para ser exibido para o usuário (sendo portanto um conteúdo dinâmico) e envia este conteúdo para o servidor web, que converte o objeto HTTPServletResponse enviado pelo servlet em uma resposta HTTP e retorna esta resposta para o usuário, podendo ser uma nova página criada pelo servlet. Tecnicamente, os servlets podem ser utilizados para o tratamento de qualquer ambiente de requisição/resposta, não sendo necessariamente para ser utilizados apenas com o protocolo

21 10 HTTP. Neste trabalho será utilizado somente o protocolo HTTP incluso no package java.servlet.http da API de servlets no JEE. 4.5 Exemplo de verificação de login em JEE Para exemplificar a utilização do JEE, será mostrado como é feita uma página de login de um sistema web que irá verificar os dados (login e senha) do usuário e fará conexão no banco de dados para verificar se esse login é válido, caso seja, é mostrada uma página para o usuário informando que o login é válido, caso contrário, será mostrada uma página informando que o login é inválido. Portanto esse exemplo que poderia ser o login de um sistema conterá: Páginas Três JSP s, a index.jsp que será responsável por recuperar as informações referente ao login do usuário, a loginvalido.jsp que informará ao usuário que o login informado é valido e a logininvalido.jsp que informará ao usuário que o login é inválido caso o mesmo não exista cadastrado no banco. Um servlet para fazer a validação do login do usuário e redirecionar para as páginas loginvalido.jsp e logininvalido.jsp. Uma classe para ser feita conexão e acesso ao banco de dados para verificar se o login informado existe cadastrado. A página index.jsp será composta por dois campos de texto contidos em um formulário, para serem informados o login e a senha, conforme seu código a seguir no exemplo <form id="formulario" action="\servleturl"> <table> <tr><td>informe os dados para o login:</td></tr> <tr><td>login: </td><td><input type="text" name="login"/></td></tr> <tr><td>senha: </td><td><input type="password" name="senha"/></td></tr> <tr><td><input type="submit" name="nome" value="ok"/></td></tr> </table> </form> Exemplo O campo Login será identificado no servlet por login, conforme a propriedade name do campo de texto da JSP. Já o campo Senha será identificado no servlet por senha, conforme a propriedade name do campo de texto da JSP. Esse é o conteúdo que mais importa da index.jsp. Seguem nos exemplos e os códigos das páginas loginvalido.jsp e logininvalido.jsp respectivamente. loginvalido.jsp <html> <head> <title>.:: Usuário Logado ::.</title>

22 11 </head> <body> <b>login válido!</b> </body> </html> Exemplo logininvalido.jsp <html> <head> <title>.:: Login Inválido ::.</title> </head> <body> <b><font color="red">login inválido!</font></b> <br> <b><font color="red">verifique o login e senha informados.</font></b> </body> </html> Exemplo As duas páginas (exemplo e 4.5.3) apenas exibem mensagens informando para o usuário se o login é válido ou não. Conexão com o banco de dados Para ser feita a conexão com o banco será utilizada a classe BancoDados. A classe realiza a conexão com o banco através de seu construtor, portanto assim que a classe for instanciada será feita a conexão com o banco de dados. A verificação do usuário, se o mesmo existe ou não cadastrado no banco de dados será realizada pelo método verificalogin, que recebe como parâmetro o login e a senha do usuário e faz a consulta no banco de dados. Abaixo seguem os principais pontos do construtor e o método verificalogin da classe. Construtor Conforme já mencionado, o construtor será responsável por realizar a conexão com o banco de dados (e consequentemente realizar tratamentos de exceções referente à conexão), portanto após a instanciação da classe BancoDados a conexão com o banco estará disponível para consulta, alterações e exclusões no banco. VerificaLogin Este é o método responsável por validar se o usuário esta cadastrado no banco ou não. public boolean verificalogin(string plogin, String psenha) throws SQLException { String squery = "SELECT * "+ " FROM USUARIO "+ " WHERE LOGIN='"+pLogin+"' "+ " AND SENHA='"+pSenha+"'"; Statement st = this.connection.createstatement(); ResultSet rs = st.executequery(squery); if(rs.first())

23 12 } return true; return false; Exemplo O trecho de código do exemplo 4.5.4, através dos dois parâmetros recebidos pelo servlet (que será explicado em seguida), o login e a senha que o usuário informou na página inicial (index.jsp), realiza uma consulta no banco verificando se existe cadastrado o usuário ou não, caso exista, é retornado true, caso não exista é retornado false para o servlet que invocará este método. Servlet O usuário entrará com os dados do login na página index.jsp e irá clicar no botão Salvar para submeter os dados ao servidor. O servidor web receberá os dados informados através de uma requisição HTTP e encaminhará a requisição do usuário para o servlet através do objeto HttpServletRequest (convertido de uma requisição HTTP). O servlet, conforme já explicado, é responsável pelo controle das requisições realizadas pelo cliente e é executado pelo servidor web. Para o servidor web executar um determinado servlet, é necessário que esse servlet esteja pré-configurado no servidor. No exemplo que segue, o servidor web utilizado é o Tomcat e a configuração de um servlet no Tomcat é feita através do arquivo web.xml, conforme exemplo web.xml Dentre outras configurações que o arquivo web.xml contém referente ao Tomcat, segue a configuração do servlet que será responsável por verificar se o login do usuário é válido ou não. <servlet> <servlet-name>servletexemplo</servlet-name> <servlet-class>servletbanco</servlet-class> </servlet> <servlet-mapping> <servlet-name>servletexemplo</servlet-name> <url-pattern>/servleturl</url-pattern> </servlet-mapping> Exemplo A tag <servlet> é onde se declara o nome e a classe do servlet, neste exemplo o nome do servlet será ServletExemplo e a classe Java do servlet será a ServletBanco. O servidor web executa um servlet de acordo com a URL que o usuário acessa, ou seja, um determinado servlet será executado quando a URL acessada pelo usuário for a que está configurada para este servlet. No exemplo o servlet ServletExemplo só será executado pelo servidor web (ou seja, pelo Tomcat) quando o usuário ou o sistema acessar a URL ServletURL, não só o usuário acessa uma determinada URL, como também o sistema pode redirecionar aplicação para uma determinada URL que é o que esta sendo feito pelo form de login da página index.jsp na propriedade action, conforme exemplo (<form id="formulario"

24 13 action="\servleturl">). Portanto a propriedade action do form é para onde será redirecionado o sistema após o clique no botão de submit do form, que neste exemplo é o botão OK, conforme consta no exemplo Após o clique no botão de OK, o servidor web executará o servlet ServletExemplo, pois o form redireciona para a URL configurada para este servlet (/ServletURL). Segue os principais trechos da classe Java ServletBanco também configurada no web.xml para o servlet ServletExemplo. Todo servlet deve herdar a classe HttpServlet a qual possui métodos utilizados para o tratamento de serviços HTTP. Portanto a classe deve possuir em sua declaração o extends HttpServlet, que no Java o extends é a palavra chave para herdar uma e somente uma classe (DEITEL, H.; DEITEL, P., 2005; JANDL, 2007). Declaração da classe: public class ServletBanco extends HttpServlet Em todo formulário de uma página HTML (form), pode ser feita uma requisição ao servidor web, esta podendo ser do tipo GET (default) ou POST. A diferença entre os dois métodos esta na codificação que o browser faz com os dados do formulário, no método GET os dados são passados através da URL sendo visível ao usuário (é passado como parâmetros na URL, separados por? inicialmente e & a partir do primeiro parâmetro, por exemplo, a URL estaria enviando os atributos id, flag e teste para o servidor com os respectivos valores 1, 2 e 3, sendo visível ao usuário através da URL), já no método GET os valores não ficam visíveis para o usuário na URL. Portanto é recomendável a utilização do GET somente quando se necessita do retorno de algum dado, já o POST pode envolver qualquer recurso, como armazenar ou alterar algo em um banco de dados ou enviar um . O servlet possui os métodos doget e dopost que são executados de acordo com o método definido pelo form (GET ou POST), ou seja, se o método do formulário for o GET, ao executar o servlet, é invocado o método doget e se for o método POST é invocado o método dopost do servlet. Como não foi definido nenhum método no formulário do exemplo 4.5.1, será utilizado o método GET, pois conforme mencionado o método GET é o default, ou seja, quando não se especifica qual o método que será utilizado em um formulário, é utilizado o método GET. No exemplo não faz diferença se o método do form é GET ou POST, independentemente do método, o servlet terá que realizar a mesma tarefa, que é a validação do login. Portanto conforme segue no exemplo 4.5.6, os método doget e dopost invocam um mesmo método, o validalogin que faz o tratamento da validação do login. protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { validalogin(request, response); } protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { validalogin(request, response); } Exemplo Segue no exemplo 4.5.7, o método invocado tanto pelo doget quanto pelo dopost.

25 14 1. protected void validalogin(httpservletrequest request, HttpServletResponse response) 2. throws ServletException, IOException 3. { 4. String login = request.getparameter("login"); 5. String senha = request.getparameter("senha"); BancoDados con = new BancoDados(); 8. RequestDispatcher dispatcher; 9. try 10. { 11. if(con.verificalogin(login, senha)) 12. { 13. dispatcher = request.getrequestdispatcher("/loginvalido.jsp"); 14. } 15. else 16. { 17. dispatcher = request.getrequestdispatcher("/logininvalido.jsp"); 18. } 19. } 20. catch(sqlexception sql) 21. { 22. dispatcher = request.getrequestdispatcher("/erro.jsp"); 23. System.err.println("Erro em verificação no banco de dados"); 24. sql.printstacktrace(); 25. } dispatcher.forward(request, response); 28. } Exemplo O método validalogin primeiramente recupera os dados do login informados pelo usuário (o login e a senha) do request que é onde os dados do form estão armazenados, conforme as linhas 4 e 5 do exemplo Para recuperar estes dados do request, é necessário invocar o método getparameter no request passando como parâmetro a propriedade name do campo que se deseja recuperar, especificado no form da página. Conforme o exemplo 4.5.1, os atributos name dos dois campos (Login e Senha), são: login e senha. Portanto o login e a senha informada pelo usuário estão armazenados respectivamente nas Strings login e senha do método validalogin. Tendo o login e senha, é necessário agora verificar no banco de dados se este login informado pelo usuário existe ou não. Esta verificação é feita através do método verificalogin do exemplo 4.5.4, este fazendo parte de uma classe chamada BancoDados que foi instanciada no servlet na linha 7. O método verificalogin recebe por parâmetro, duas Strings, sendo o login e a senha do usuário e como já foi recuperado ambos, é chamado o método verificalogin passando os dois dados do login do usuário na linha 11. Caso o login do usuário exista no banco de dados, o método retorna true, fazendo entrar na validação que insere no request a página loginvalido.jsp através do método getrequestdispatcher (conforme linha 13) para posteriormente ser redirecionada a aplicação através do método forward, caso o login não exista no banco de dados, é redirecionado para a página logininvalido.jsp (linha 17). Seguindo a boa prática de programação, foi feito um tratamento caso ocorra algum erro na verificação do login no banco, utilizando o recurso de tratamento de exceções que o Java disponibiliza (o bloco try/catch). Caso ocorra algum erro na verificação no banco de dados (este sendo a exeção), é inserido no request o redirecionamento da página erro.jsp.

26 E finalmente na linha 27 são redirecionados o request e o response para a página que foi determinada pela lógica aplicada. 15

27 16 5. JSF O JSF é um framework para o desenvolvimento web que utiliza a plataforma Java (JEE), portanto é multiplataforma (é um dos frameworks utilizados para o desenvolvimento do protótipo de um sistema web neste trabalho), todas as aplicações JSF são aplicações web Java padrão que controlam as requisições e respostas HTTP via Servlet e eventualmente utiliza tecnologias para a visualização do conteúdo gerado (que pode ser dinâmico) como a Java Server Pages (JSP). Também conhecido por Faces, o JSF faz com que se torne mais fácil o desenvolvimento web baseado em componentes, o framework possui vários componentes gráficos prontos, como tabelas, caixas de texto, botões, entre outros, sendo que cada componente não é um simples componente HTML, estes possuem suas propriedades no JSF que visa facilitar o desenvolvimento e conseqüentemente ganhar produtividade e tempo de desenvolvimento. Netbeans (2007a), o framework JSF é uma API (Application Programming Language) padrão Java para a construção de componentes de interface com o usuário em aplicações web. Pode-se pensar que o JSF seria uma caixa de ferramentas cheia de componentes prontos para serem utilizados e que podem ser facilmente e rapidamente reutilizados em aplicações web. Estes componentes podem ser simples, como um campo para a entrada de um texto, ou complexos, como um campo de data formatado que exibe uma janela pop-up para a seleção da data. Existem projetos como o MyFaces da Apache (ASF, 2007c) que possuem outros componentes prontos com suas próprias características, estendendo assim as possibilidades de usabilidade de componentes, não se limitando apenas aos componentes nativos do JSF, sendo que é possível também ser desenvolvido um componente de acordo com uma situação/problema que o desenvolvedor deparar. Portanto o JSF facilita muito o desenvolvimento de interfaces com o usuário para sistemas web em Java. As classes JSF podem ser organizadas em quatro principais categorias: Aplicação: são divididas em duas áreas, a classe Application que representa a aplicação como um todo e as lógicas da aplicação que são organizadas em backing beans que serão explicados posteriormente. Similar ao ServletContext em relação à servlets. Contexto: basicamente são classes utilizadas para ser feito o acesso nos dados contidos na requisição atual, podendo-se fazer uma analogia com o HttpServletRequest utilizado nos servlets. Tratamento de eventos: responsável pelo tratamento da interação que o usuário faz com a aplicação, como acessar um botão ou alterar o valor de um campo de texto. Nos servlets os eventos são o request e no JSF os parâmetros do request são transformados em objetos de evento e podem ser escritos listeners pelo desenvolvedor para ser feito o tratamento destes eventos. Componentes para interface gráfica com o usuário que é toda a visão que o JSF disponibiliza ao usuário que pode ser controlada com código Java. Estes componentes não tendo uma equivalência com os servlets, pois estes não possuem um modelo de componentes do mesmo nível. O JSF possui componentes que são orientados a evento, assim como uma aplicação desktop desenvolvida com a utilização de AWT/SWING trataria o evento do acionamento de

28 17 um botão, o JSF trataria basicamente da mesma forma, exceto pelo fato do tratamento das requisições e respostas HTTP. Entre algumas facilidades que o JSF proporciona, esta a validação que pode ser feita nos componentes, como por exemplo, a restrição de um valor inserido em um componente de inserção de texto na página será validada pelo framework, não necessitando assim o desenvolvedor construir uma classe específica para validação. Com este recurso de eventos que os componentes do JSF proporciona, o desenvolvedor em momento algum necessita ter contato direto com servlets, a não ser em casos extremos em que é necessária a implementação de servlets no framework, mas isso não quer dizer que o JSF não utiliza servlets, pois conforme já explicado, o JSF utiliza a tecnologia JEE, esta possuindo a interação com servlet, portanto, mesmo o desenvolvedor não tendo o contato direto com os servlets, o framework internamente faz todo o tratamento de requisições e respostas HTTP e faz a devida utilização de servlets quando necessário. Figura Nível de abstração de tecnologias utilizadas no JSF (MANN, 2005) A figura 5.1 mostra o nível de abstração entre as tecnologias que o JSF utiliza, desde o servidor web que começa o tratamento das requisições do usuário (requisições e respostas HTTP), a API de servlets, que são os métodos e classes disponibilizadas para a utilização dos servlets, as JSP s que são as páginas escritas em Java que no final resultam em HTML, até a

29 18 própria utilização do framework que é onde se consegue obter o maior nível de abstração, conforme mostrado na figura Internacionalização Uma funcionalidade importante que grandes aplicações devem ter é a internacionalização das mensagens que a mesma exibe. Se uma aplicação é utilizada em mais de um país, suas mensagens devem ser de acordo com o idioma acessado. Por exemplo, uma mesma aplicação é utilizada no Brasil e na Inglaterra, e esta aplicação possui uma mensagem de Bem-Vindo na página inicial, o desenvolvedor não precisaria criar duas páginas de início, uma contendo o Bem-Vindo para os usuários que acessam a aplicação no Brasil e outra contendo Welcome para os que acessam na Inglaterra, poderia-se criar arquivos que conteriam a devida tradução da mensagem e uma mesma página acessa estes arquivos para recuperar a mensagem devidamente traduzida, separando as páginas das mensagens de tradução, facilitando assim a manutenção do sistema. As aplicações JSF suportam a internacionalização de seu conteúdo, podendo assim modificar os labels e mensagens do sistema de acordo com o idioma que o usuário esta acessando. Uma aplicação é pré-configurada com os idiomas que se tem suporte e possui um ResourceBundle (arquivo que contém as mensagens utilizadas no sistema com sua devida tradução, cada idioma possui um ResourceBundle) contendo as mensagens traduzidas para cada idioma suportado. Para ser feita esta internacionalização, primeiramente é necessário que esteja configurado no arquivo faces-config.xml quais os idiomas suportados pela aplicação e posteriormente é feito a instanciação de um ResourceBudle (presente no Java SDK (Software Development Kit), na package java.util.resoucebundle), para recuperar a localização base dos ResourceBundles do sistema é necessário invocar o método getmessagebundle do objeto que representa a aplicação, portanto se utilizaria o seguinte comando: application.getmessagebundle() e a partir do nome base do ResourceBundle, é criado um de acordo com o idioma do usuário, onde poderão ser recuperadas as mensagens pré traduzidas do idioma determinado. Configuração dos idiomas da aplicação no arquivo faces-config.xml: <application> <locale-config> <default-locale>pt</default-locale> <supported-locale>en_us</supported-locale> </locale-config> <message-bundle> resource.mensagens.arquivodemensagens </message-bundle> </application> Exemplo Recuperação do local das mensagens: String diretorio = facescontext.getapplication().getmessagebundle();

30 19 A string diretorio após o comando realizado teria o valor resource.mensagens.arquivodemensagens que foi recuperado do arquivo de configuração faces-config.xml, conforme exemplo Tendo o caminho do ResourceBundle ArquivoDeMensagens é feito o tratamento para a recuperação das mensagens traduzidas do ResourceBundle do idioma solicitado (este é recuperado através do local da aplicação do usuário, que se obtém no JSF pelo comando facescontext.getviewroot().getlocale()). Se o idioma do usuário fosse o inglês dos Estados Unidos, o ResourceBundle que conteria as mensagens traduzidas para o inglês seria o ArquivoDeMensagens_en_US. 5.2 Backing Beans Backing Bean é um dos recursos mais importantes e utilizados no JSF, são classes Java que fazem o tratamento de eventos e determinadas lógicas no JSF. São as classes que possuem os métodos que são executados ao usuário clicar em um link ou em botão por exemplo. Segundo Mann (2005), Backing Beans são JavaBeans especializados que coletam valores dos componentes de interface com o usuário e implementam métodos de listener events. Podem também tratar referências para os componentes de interface com o usuário. Os Backing Beans são configurados no arquivo de configuração do JSF, o facesconfig.xml, onde é mencionado qual a classe Java que o backing bean utilizará, o nome que será invocado nas JSP s para ser feito o acesso a este backing bean e o escopo que terá na aplicação, podendo ser definido para ser uma classe que será instanciada somente uma vez na aplicação, podendo ser reutilizada essa instancia durante todo o ciclo da aplicação ou então ser definido este backing bean para manter sua instancia somente durante a sessão do usuário. Segue um exemplo de como é configurado um backing bean e como este é invocado por uma JSP. Primeiramente deve-se configurar o backing bean no arquivo faces-config.xml da maneira como segue no exemplo <managed-bean> 2. <description>descrição do Backing Bean</description> 3. <managed-bean-name>teste</managed-bean-name> 4. <managed-bean-class>beans.backingbeanteste</managed-bean-class> 5. <managed-bean-scope>session</managed-bean-scope> 6. </managed-bean> Exemplo Conforme exemplo 5.2.1, um backing bean é declarado através da tag <managedbean>, esta possuindo os seguintes atributos: <description>: descricaçãodo backing bean declarado, pode ser utilizado para especificar qual a funcionalidade do backing bean na aplicação, facilitando a manutenção. <managed-bean-name>: o nome pelo qual o backing bean será invocado nas JSP s. <managed-bean-class>: a classe Java que será o backing bean.

31 20 <managed-bean-scope>: o escopo que a instância deste backing bean será mantido na aplicação. Pode-se utilizar os seguintes escopos: none (a cada acesso ao backing bean, uma nova instância é criada), session (o backing bean irá manter sua instância durante a sessão), application (manterá a instância do backing bean durante toda a aplicação) e request (a instância será mantida durante a requisição que esta sendo feita). Após o backing bean estar devidamente configurado, o mesmo já pode ser invocado por uma JSP da seguinte forma: 1. <h:commandbutton id="commandbutton" 2. type="submit" 3. value="invocar Backing Bean" 4. action="#{teste.metodoteste}"/> Exemplo (Botão que ao ser clicado invoca o método metodoteste do backing bean teste ). Na JSP o backing bean é invocado através do nome determinado no arquivo de configuração na tag <managed-bean-name> (que conforme exemplo é teste) juntamente com o método que será executado, ficando da seguinte forma: nomedobackingbean.nomedometodo, como se encontra no exemplo na linha Eventos no JSF Um evento é uma ação que usuário realiza no sistema, como o clique em um botão, o arrastar de um objeto ou a digitação de alguma tecla. O JSF suporta o tratamento de eventos em componentes, portanto se o usuário clicar em um botão ou em um link (componentes do JSF), essa ação irá gerar um evento que será tratado em uma classe Java especificada naquele componente em que o usuário provocou o evento. Tecnicamente, um evento é uma instância da classe ActionEvent que fica localizada na package javax.faces.event. A classe ActionEvent implementa a interface ActionListener, localizada também na package javax.faces.event. O eventos criados pelos componentes JSF são adicionados na instância corrente da classe FacesContext. Uma funcionalidade muito utilizada no JSF é a integração dos eventos com os backing beans, que clicando em um botão, por exemplo, é executado um determinado método de um backing bean. Para exemplificar o tratamento de eventos que o JSF proporciona, segue um exemplo de um botão que ao ser clicado, o framework envia o evento à classe Java respectiva daquele botão (o backing bean). O exemplo que segue é referente ao evento de um clique de botão em uma JSP que ao ser clicado é executado o método imprime de um backing bean que apenas imprime na saída padrão o texto Método do Backing Bean Executado!. Backing Bean Configuração do Backing Bean no arquivo faces-config.xml:

32 21 1. <managed-bean> 2. <description>teste de Backing Bean</description> 3. <managed-bean-name>testebackingbean</managed-bean-name> 4. <managed-bean-class>beans.testebackingbean</managed-bean-class> 5. <managed-bean-scope>session</managed-bean-scope> 6. </managed-bean> Exemplo Classe Java que será o backing bean: 1. package beans; public class TesteBackingBean 4. { 5. public void imprime() 6. { 7. System.out.println("Método do Backing Bean Executado!"); 8. } 9. } Exemplo O backing bean possui apenas um método, o imprime (linha 5 do exemplo 5.3.2) que nada mais faz que imprimir na saída padrão o texto Método do Backing Bean Executado!. JSP Configurado o backing bean, será desenvolvida agora a JSP que conterá o botão que ao ser clicado executará o método imprime do backing bean. 1. <%@ taglib uri=" prefix="f" %> 2. <%@ taglib uri=" prefix="h" %> <f:view> 5. <html> 6. <body> 7. <h:form> 8. <h:commandbutton id="commandlogar" 9. type="submit" 10. value="clique Aqui" 11. action="#{testebackingbean.imprime}"/> 12. </h:form> 13. </body> 14. </html> 15. </f:view> Exemplo Referente ao exemplo 5.3.3, primeiramente são incluídas as taglibs necessárias para a utilização da API do JSF, nas linhas 1 e 2. Dentro do <h:form> (responsável pela renderização de um form na página HTML que será gerada ao final) na linha 7 é inserido o botão e no JSF para inserir um botão com um evento que executa um determinado método de um backing bean é necessário a utilização do commandbutton, conforme linha 8. O commandbutton possui vários atributos, mas neste caso foram utilizados o id (identificador do botão na página HTML que será renderizada), type

33 22 (tipo do botão, neste caso será o botão de envio das informações do form, ou seja, o submit), value (texto que botão conterá) e finalmente o action que é ação que será realizada pelo commandbutton ao ser clicado e neste exemplo será executado o método imprime do backing bean TesteBackingBean, quando se faz referência à backing beans em JSP s, utiliza-se o nome do backing bean que foi determinado no arquivo de configuração faces-config.xml no atributo <managed-bean-name>, conforme linha 3 do exemplo que neste caso é testebackingbean, ficando portanto no atributo action do commandbutton o nome do backing bean seguido por seu método que será invocado (testebackingbean.imprime). Após o usuário clicar no botão Clique Aqui na pagina HTML, será executado o método imprime (linha 5 do exemplo 5.3.2) e conseqüentemente será impresso na saída padrão o texto Método do Backing Bean Executado!. 5.4 Componentes O JSF é um framework baseado em componentes e estes facilitam o desenvolvimento e aumentam a produtividade, uma vez utilizando-os, se obtém um reaproveitamento de código mais amplo. A utilização de componentes pode também trazer uma qualidade maior na aplicação, utilizando componentes de terceiros que possuem uma credibilidade boa no mercado e que é confiável, a aplicação estará implementando também a melhor maneira em que poderia ser feita aquela tarefa que o componente é responsável por fazer, sendo que o componente foi desenvolvido seguindo as melhores práticas e engenharias de software pela empresa que o disponibilizou. Além dos vários componentes prontos que o JSF possui, o framework contém também uma API específica para a construção de componentes, estes portanto podendo ser desenvolvidos por terceiros. Um exemplo de componentes de terceiro, são os componentes desenvolvidos pelo projeto MyFaces (ASF, 2007c), o projeto possui componentes para diversas tarefas, estendendo assim a quantidade de componentes em que se pode ter acesso na utilização do JSF. Mesmo existindo os componentes de terceiros e os nativos do JSF, um sistema ou uma aplicação pode se deparar em uma situação em que a utilização de um componente facilitaria muito, além de trazer todas as vantagens mencionadas referente à utilização de componentes, mas nem o JSF e nem terceiros possuem um componente com estas características desejadas pela solução. É partindo deste ponto em que se torna necessário a construção de seu próprio componente, fazendo com que este possua todas as características necessárias, ou seja, faça a tarefa exatamente da forma que se espera. Portanto, o ideal é pesquisar se não existe nenhum componente atualmente que faça a tarefa desejada de maneira coerente e se caso não existir nenhum componente com o comportamento desejado, é feito a construção de um componente específico, podendo posteriormente este ser disponibilizado para outros desenvolvedores que possam se depararar com a mesma situação que necessite da utilização do componente. 5.5 API para desenvolvimento de componentes gráficos no JSF O JSF possui uma arquitetura extensível que permite a criação de componentes gráficos para ser feita a interface com o usuário, permitindo assim que terceiros desenvolvam seus próprios componentes gráficos fazendo utilização da API de criação de componentes do JSF.

34 23 Segundo Hightower (2007), a funcionalidade dos componentes JSF, tipicamente centraliza-se em duas ações: codificar e descodificar dados. Descodificar é o processo de converter os parâmetros das requisições recebidas para os valores do componente. Codificar é o processo de converter os valores correntes do componente no markup correspondente, ou seja, o HTML. A criação de um componente no JSF consiste de três tarefas: Herdar as classes específicas e/ou implementar as interfaces específicas necessárias. Usualmente se torna necessário a utilização de uma classe ou interface específica para a criação de um componente. Adicionar as configurações necessárias no arquivo de configuração do JSF. Assim como muitas outras tarefas no JSF, é necessário ser feita a configuração do componente no arquivo XML (Extensible Markup Language) de configuração do JSF, o faces-config.xml. Para toda extensão desenvolvida no JSF, é necessário possuir uma entrada de configuração correspondente. Integrar a nova classe (o novo componente) com uma tecnologia de exibição, como por exemplo a JSP, este sendo portanto o último passo para a utilização do componente no processo de desenvolvimento. Para o desenvolvimento de um componente, primeiramente deve-se criar sua respectiva classe Java contendo seus atributos e esta herdando uma outra classe do framework JSF de acordo com a tarefa em que o componente será responsável por realizar. Por exemplo, se for desenvolver um componente que irá exibir algum atributo de um backing bean, este componente deve herdar a classe javax.faces.component.uioutput que é responsável pela ligação entre o componente e os atributos que serão recuperados os valores do backing bean. Caso o componente for renderizar um componente HTML para o cliente (possuir a tarefa de escrever algum código HTML para devolver para o cliente), é necessário este possuir uma classe que será responsável pela criação de todo o código HTML que será devolvido para o cliente, a classe é denominada como o renderer do componente e deve estender a classe javax.faces.render.renderer, esta contendo métodos responsáveis pela renderização do código HTML que o componente irá escrever. E por último, é necessário o componente possuir outra classe que estenda a classe javax.faces.webapp.uicomponenttag, é através desta classe juntamente com a tag library descriptor (que é um arquivo onde estão todos os atributos utilizados dos componentes e onde é feito a ligação destes atributos com suas respectivas classes Java) que serão encontrados os atributos que o componente possui e que são utilizados em uma JSP por exemplo. Exemplificando o que foi mencionado referente à criação de componentes gráficos no JSF, será desenvolvido um componente que renderiza para o cliente um formulário para o preenchimento de login, como a maioria das telas referente a login possui dois campos para a entrada dos dados, ou seja, o login e a senha, será desenvolvido um componente que rederizará estes dois campos para a entrada dos dados, sendo que estes dois campos possuíram relacionamento com atributos de um determinado backing bean de acordo com o que o desenvolvedor mencionar através de uma EL (Expression Language), ou seja, os dados inseridos estarão ligados diretamente com uma classe Java que posteriormente poderá utilizar estes dados informados pelo usuário para fazer a validação do login, se o mesmo é válido ou não.

35 24 Classes Java: O componente possuirá três classes, a classe que representará o componente, uma classe que será o renderer do componente, que conforme já mencionado é responsável por criar os códigos HTML necessários para o componente, e por último possuirá uma classe que conterá as configurações referentes aos atributos que serão utilizados na JSP para a utilização do componente, estes atributos podendo ser denominados por tags. A classe que representará o componente irá herdar a classe javax.faces.component.uioutput, pois esta super classe (classe pai) contém implementações já prontas no que se refere a escrita de saída em HTML, e como o componente irá escrever códigos, será utilizada a classe UIOutuput, caso o componente fosse um campo que recebe entrada de dados, este deveria herdar a classe UIInput que da mesma forma que a UIOutput é para a saída de dados a UIInput é para a entrada de dados. 1. public class Login extends UIOutput 2. { 3. public static final String FAMILY = "LOGIN_TCC"; public Login() 6. { 7. super(); 8. } public String getfamily() 11. { 12. return FAMILY; 13. } 14. } Exemplo Conforme o exemplo 5.5.1, outra particularidade da classe é que ela possui o método getfamily() (linha 10) que retorna a família que este componente pertence, esta família é utilizada para saber posteriormente qual é o renderer do componente quando for feita a geração do HTML através do arquivo de configuração onde o componente será registrado (esta tarefa será feita posteriormente). Uma das tarefas da classe também é chamar o construtor de sua super classe (UIOutput) este contendo tarefas necessárias para os componentes que geram valores de saída conforme explicado anteriormente (linha 7). Renderer: Outra classe Java que o componente conterá é a classe que será o renderer (que conforme já explicado é onde são gerados os códigos HTML que serão enviados para o cliente), para uma classe ser um renderer, esta deve estender a classe javax.faces.render.renderer. Portanto o renderer do componente que renderizará o formulário para login ficará da seguinte forma: public class LoginRenderer extends Renderer Exemplo Uma classe renderer pode possuir os seguintes métodos que são (não obrigatoriamente) sobrescritos, pois estes pertencem a super classe Renderer (conforme exemplo 5.5.2) para o controle e geração do código HTML que irá ser devolvido ou enviado para o cliente:

36 25 decode (FacesContext, UIComponent) o Este método é responsável por recuperar qualquer parâmetro passado pelo form do HTML e armazenar valores no componente. A primeira tarefa que este método deve realizar que faz parte de sua especificação é certificar de que os atributos e o contexto não estão nulos. encodebegin (FacesContext, UIComponent) o É onde é feita a implementação inicial do código HTML que será gerado, é o primeiro método a ser chamado para a renderização do HTML. encodechildren (FacesContext, UIComponent) o Caso o componente possua outros sub componentes, ou seja, componentes que serão filhos deste, é através deste método que será recuperado os componentes filhos e será feita a lógica necessária para o tratamento de seus sub componentes. Este método só é executado se a classe renderer possuir um outro método, o getrenderschildren() retornando true, este método pertence a super classe Renderer e caso este método não seja sobrescrito, é retornado false, portanto o default é não ser feita a execução do método encodechildren, este só sendo executado quando a classe que representará o renderer possuir o método getrenderschildren() sobrescrito retornando true. encodeend (FacesContext, UIComponent) o Onde é feita a implementação final do código HTML que será gerado, onde pode ser fechada uma tag table que foi iniciada no encodebegin por exemplo. É o último método a ser invocado no processo de renderização de código HTML do componente que possui o renderer. Caso o componente não possuir sub componentes, ou seja, não possuir nenhum componente filho, toda a lógica de codificação do HTML pode ser desenvolvida apenas no método encodebegin. Concluindo, a codificação do código HTML que o renderer do componente irá gerar possui o seguinte processo: primeiramente é chamado o método encodebegin, após sua execução é chamado o método encodechildren, este sendo chamado somente se a classe possuir o método getrenderschildren() retornando true e por último é chamado o método encodeend, finalizando assim o processo de geração do código HTML até onde o desenvolvedor possui o maior acesso. 1. public boolean getrenderschildren() 2. { 3. return true; 4. } 5. public void encodebegin(facescontext context, UIComponent component) throws IOException 6. { 7. ResponseWriter writer = context.getresponsewriter(); writer.startelement("table", component); 10. writer.startelement("tr", component); 11. writer.startelement("td", component); 12. writer.write((string)component.getattributes().get("label")); 13. writer.endelement("td");

37 writer.endelement("tr"); 15. writer.flush(); 16. } public void encodechildren(facescontext context, UIComponent component) throws IOException 19. { 20. ResponseWriter writer = context.getresponsewriter(); 21. Iterator inputs = component.getchildren().iterator(); UIComponent componente = (UIComponent)inputs.next(); 24. writer.startelement("tr", component); 25. writer.startelement("td", component); 26. writer.write("login: "); 27. writer.endelement("td"); 28. writer.startelement("td", component); 29. componente.encodebegin(context); 30. componente.encodeend(context); 31. writer.endelement("td"); 32. writer.endelement("tr"); 33. writer.startelement("tr", component); 34. writer.startelement("td", component); 35. writer.write("senha: "); 36. writer.endelement("td"); 37. writer.startelement("td", component); 38. componente = (UIComponent)inputs.next(); 39. componente.encodebegin(context); 40. componente.encodeend(context); 41. writer.endelement("td"); 42. writer.endelement("tr"); 43. writer.flush(); 44. } public void encodeend(facescontext context, UIComponent component) throws IOException 47. { 48. ResponseWriter writer = context.getresponsewriter(); 49. writer.endelement("table"); 50. } Exemplo O exemplo mostra como fica o código que cria todo o conteúdo HTML referente ao componente. Primeiramente na linha 1, o método getrenderschildren esta retornando true, portanto o método encodechildren será invocado pelo framework para o tratamento de seus respectivos filhos ou sub componentes. No método encodebegin na linha 5, é recuperado o objeto onde será escrito o código HTML que será devolvido para o browser do cliente, este sendo o objeto writer do tipo ResponseWriter na linha 7, contendo o retorno do método context.getresponsewriter() que retorna o objeto de escrita (do tipo ResponseWriter) da requisição corrente para posteriormente ser devolvida com novos códigos HTML. Para ser inserida uma tag HTML no response que será enviado para o cliente, é utilizado o método startelement presente na classe ResponseWriter, através deste método é que se inicia uma tag, por exemplo, para iniciar a tag <table>, utilizaria-se o método startelement da seguinte forma: <objeto>.startelement( table ), e o framework renderizaria a tag table da forma correta no cliente e para fechar uma tag HTML, utiliza-se o método endelement, portanto o fechamento da mesma tag table, seria feito da seguinte forma: <objeto>.endelement( table ) que resultaria no código HTML </table>.

38 27 Os atributos inseridos na JSP pelo desenvolvedor são recuperados desta forma: componente.getattributes().get("nome_do_atributo"), portanto conforme a linha 12, será inserido no código HTML criado pelo componente o que o desenvolvedor especificou no atributo label na JSP que pode ser melhor observado na utilização deste componente na JSP, mais a frente. Após ser executado o encodebegin, será executado o método encodechildren para o tratamento dos filhos. Da mesma forma que no encodebegin é recuperado o objeto que representará a resposta (ou o response) que será enviada para o cliente, é feita esta recuperação no encodechildren, conforme linha 20. Os filhos do componente são recuperados na linha 21, estes sendo tratados através de um objeto do tipo Iterator, onde se pode, por exemplo, ser feito um laço/loop para o tratamento de todos os filhos, percorrendo estes componentes filhos, caso a quantidade de componentes filhos que um componente possuir for grande ou indeterminada. Como no caso deste componente irão existir apenas dois componentes filhos, um campo para entrada do login e um campo para a entrada da senha, portanto não foi feito um laço para a recuperação dos filhos. O primeiro componente filho recuperado é armazenado no objeto componente (linha 23) do tipo UIComponent que representa os componentes gráficos de interface com o usuário do JSF e nas linhas 29 e 30 são chamados os métodos encodebegin e encodeend respectivamente do componente filho, este componente filho será do tipo UIInput que é um componente já definido e implementado no JSF para a inserção de dados, portanto será feita a renderização do código HTML necessário dos componentes filhos através dos métodos encodebegin e encodeend dentro da tag HTML <td> representando um dado de uma linha de uma tabela HTML, esta tag sendo iniciada na linha 28 e fechada na linha 31, criando-se portanto: <td> código do HTML renderizado pelos métodos encodebegin e encodechildren </td> O mesmo procedimento é feito para o segundo componente que é um novo campo para a inserção de dados, na linha 38 é recuperado o próximo componente filho através do iterator e nas linhas 39 e 40 são invocados os métodos encodebegin e encodechildren para a renderização do código HTML deste segundo componente filho. Como o componente renderizará uma tabela HTML para a geração deste formulário para o login, o segundo componente é inserido em uma nova linha da uma tabela HTML, cuja tag é representada por <tr>, esta é iniciada na linha 33 e fechada na linha 42, este mesmo procedimento de iniciar uma nova linha para a inserção do componente filho foi feito para o primeiro componente filho, onde a tag <tr> foi iniciada na linha 24 e fechada na linha 32. E finalizando o processo de renderização do código HTML que o componente gera para ser feito o envio para o browser do cliente, o framework faz a chamada do método encodeend (linha 46), onde este nada mais faz do que fechar a tag <table> (linha 49) que foi iniciada no encodebegin (linha 9). Até o momento o componente possui a sua classe representativa e o seu Renderer, por último é necessário possuir também uma classe contendo o devido tratamento para as tags ou os atributos que o desenvolvedor irá utilizar na JSP para a renderização do componente no browser do usuário. As classes que fazem este tratamento dos atributos devem estender a classe javax.faces.webapp.uicomponenttag, esta possuindo o devido tratamento e as devidas tarefas para o componente. Portanto conforme o exemplo 5.5.4, a classe possuirá a seguinte assinatura:

39 28 public class LoginTag extends UIComponentTag Exemplo Esta classe deve implementar alguns métodos contidos na classe UIComponentTag, estes sendo responsáveis por retornar informações do componente para que o framework recupere as devidas classes no arquivo de configuração faces-config.xml. Os métodos que devem ser implementados são: getcomponenttype, getrenderertype e setproperties, conforme segue no exemplo private static final String LOGIN = "LOGIN"; 2. private static final String LOGIN_RENDERER = "LOGIN_RENDERER"; public String getcomponenttype() 5. { 6. return LOGIN; 7. } public String getrenderertype() 10. { 11. return LOGIN_RENDERER; 12. } protected void setproperties (UIComponent component) 15. { 16. super.setproperties(component); 17. component.getattributes().put("label", label); 18. } Exemplo No exemplo na linha 4, o método getcomponenttype retorna o tipo do componente, para que o framework localize a respectiva classe do componente no arquivo de configuração (faces-config.xml). O método getrenderertype retorna o tipo do Renderer do componente para ser possível ser feita a localização da classe que representa o Renderer do componente. E por último o método setproperties é responsável por armazenar no contexto da aplicação os atributos que o desenvolvedor utilizou do componente na JSP para que posteriormente seja possível recuperar estes atributos, assim como foi feito na linha 12 do exemplo Portanto o atributo label é recuperado da JSP e armazenado no componente na linha 17 do exemplo e é recuperado para inserir no código HTML, no renderer do componente, no exemplo Para uma melhor manutenção do código e facilidade no desenvolvimento, é uma boa prática os atributos retornados pelos métodos getcomponenttype e getrenderertype, serem constantes, assim como foram declarados nas linhas 1 e 2 do exemplo Portanto o tipo do componente é LOGIN e o tipo do renderer do componente é LOGIN_RENDERER, estes valores são utilizados pelo framework para encontrar quais as classes Java serão utilizadas em todo processo que o componente realiza. Configuração do componente: Conforme já explicado, todo componente de interface do JSF deve ser configurado para que o framework possa recuperar suas classes e recursos corretamente. A configuração dos componentes são feitas no arquivo faces-config.xml que já foi utilizado para outros fins, é neste arquivo que ficam as principais configurações do JSF.

40 29 Segue no exemplo a configuração necessária para o funcionamento do componente no arquivo de configuração, juntamente com sua explicação: 1. <component> 2. <component-type>login</component-type> 3. <component-class>exemplotcc.login</component-class> 4. </component> Exemplo A primeira etapa que deve ser feita é especificar a classe que representará o componente, esta sendo a classe mostrada no exemplo Esta especificação é inserida dentro da tag <component>, onde <component-type> conterá o tipo do componente, este sendo retornado pelo método getcomponenttype na linha 6 do exemplo O framework recuperando qual o tipo do componente, através da classe que trata os atributos do componente, irá verificar no arquivo de configuração, na tag <component-class> qual a classe do componente para ser feito a execução do componente que conforme a linha 3 do exemplo a classe que representa o componente é a classe Login que esta localizada na package exemplotcc. O próximo passo a ser realizado é configurar no mesmo arquivo o renderer do componente, ou seja, qual será a classe que representará o renderer. 1. <render-kit> 2. <renderer> 3. <description>renderer para o componente de login</description> 4. <component-family>login_tcc</component-family> 5. <renderer-type>login_renderer</renderer-type> 6. <renderer-class>exemplotcc.loginrenderer</renderer-class> 7. </renderer> 8. </render-kit> Exemplo Conforme o exemplo 5.5.7, a configuração do renderer deve ser feita na tag <renderkit>, esta contendo a sub tag <renderer> (linha 2) que a partir desta sub tag será efetivamente configurado o renderer. Na linha 3, encontra-se a descrição do rederer, esta visando facilitar a manutenção da aplicação e até mesmo o desenvolvimento, facilitando por exemplo a visualização das tarefas de um determinado renderer, uma vez que estas tarefas estando descritas na tag <description>, o desenvolvedor somente lendo sua especificação já sabe o os principais fundamentos do renderer. Na linha 4, a tag <component-family> deve conter o conteúdo retornado pelo método getfamily que conforme a linha 12 do exemplo 5.5.1, retorna LOGIN_TCC, portanto o framework consegue localizar seu renderer através da família do componente retornada pela sua respectiva classe. Na linha 5, na tag <renderertype>, se encontra qual o tipo do renderer, este sendo retornado pelo método getrenderertype na classe responsável por tratar os atributos do componente (conforme linha 11 do exemplo 5.5.5). E por último na linha 6 do exemplo é especificado qual a classe Java que será o renderer do componente, na tag <renderer-class>, neste componente criado como exemplo, o renderer será a classe LoginRenderer que se encontra no pacote exemplotcc. Utilização do componente em uma tecnologia de visualização: Conforme já mencionado anteriormente, a última etapa para a completa utilização de um componente de interface gráfica com o usuário no JSF, é integrar este novo componente

41 30 com uma tecnologia de exibição, no exemplo que segue da utilização do componente, será utilizada a tecnologia JSP. A tecnologia JSP possui a possibilidade de se desenvolver módulos reutilizáveis, estes chamados de ações customizáveis (também conhecido por custom actions), uma ação customizável é invocada quando é feita a utilização de uma tag customizável dentro de uma página JSP. Essas tags devem ser definidas em um arquivo denominado por tag library (que no português significa biblioteca de tags). As particularidades de um tag library são: deve ser um arquivo com a extensão TLD (Tag Library Descriptor) e deve possuir determinadas regras em seu conteúdo, essas regras são padronizadas para a utilização em qualquer tag library. No exemplo segue as configurações necessárias somente referente à utilização do componente criado para a exibição de um formulário de login. 1. <uri>tcc_components</uri> 2. <description>tcc componentes tags</description> <tag> 5. <name>login</name> 6. <tag-class>exemplotcc.logintag</tag-class> 7. <attribute> 8. <name>label</name> 9. </attribute> 10. </tag> Exemplo Conforme no exemplo 5.5.8, na primeira linha é inserida a identificação da tag library, no atributo <uri> (que significa URI - Uniform Resource Identifier, que traduzindo seria Identificador de Fonte Uniforme) para ser utilizada na JSP posteriormente. Na segunda linha é inserida uma descrição referente a tag library. Uma tag é criada na tag library através do atributo <tag> (linha 4 do exemplo 5.5.8), no atributo <name> é informado o nome da tag criada que será utilizada na JSP (linha 5), no atributo <tag-class> é informado a classe que será correspondente desta tag criada, que conforme a linha 6 é a classe LoginTag presente no pacote exemplotcc (esta classe sendo a mesma mostrada no exemplo 5.5.5). E finalmente são informados quais os atributos que serão utilizados na tag criada, os atributos são criados na tag library através da utilização do atributo <attribute> que dentro deste atributo esta contido o atributo <name>, este sim contendo o nome do atributo que será utilizado na tag na JSP (conforme linhas 7, 8 e 9). Tendo a tag library configurada para as tags e atributos que o componente utilizará, resta somente utilizar o componente na JSP para esta comandar a geração do código HTML no browser do cliente posteriormente. Primeiramente, é necessário inserir na JSP a identificação da tag library que conterá as tags e atributos que o componente utilizará, esta inserção é feita conforme mostra o exemplo <%@ taglib uri="tcc_components" prefix="tcccomponent" %> Exemplo No exemplo 5.5.9, o atributo uri indica qual a tag library será utilizada, e conforme foi mostrado no exemplo na linha 1, a identificação da tag library que contém as configurações necessárias para a utilização do componente é tcc_components. No atributo prefix é informado como será utilizada a tag library, ou seja, como ela será identificada na JSP.

42 31 1. <f:view> 2. <html> 3. <head> <title>.:: Exemplo de componente do TCC ::.</title> </head> 4. <body> 5. <h:form id="form" > <tcccomponent:login label=".:: Dados para o Login ::."> 8. <h:inputtext value="#{validaloginbean.login}" /> 9. <h:inputtext value="#{validaloginbean.senha}" /> 10. </tcccomponent:login> <h:commandbutton id="commandlogar" 13. type="submit" 14. value="logar" 15. action="#{validaloginbean.validalogin}"/> 16. </h:form> 17. </body> 18. </html> 19. </f:view> Exemplo No exemplo , para facilitar a visualização, os trechos em negrito são onde são utilizados componentes padrões do JSF, já os trechos sem destaque são tags padrões do HTML, que não sofrerão alterações até o final da renderização da JSP, virando puro HTML. O trecho em itálico é onde foi utilizado o novo componente criado, que posteriormente irá renderizar no browser do usuário um formulário simples para a entrada de login. Tratando agora especificamente do componente criado, na linha 7 é onde se inicia a tag correspondente do componente e na linha 10 é onde se termina o componente na JSP, portanto todos os componentes filhos devem estar dentro da tag <tcccomponent:login>, esta tag possui login em sua identificação, este podendo ser encontrado na tag library e conforme a linha 7, contém apenas o atributo label (também encontrado na tag library) para a exibição do título do formulário de login, portanto o título do formulário que será exibido no browser do cliente será.:: Dados para o Login ::. (conforme inserido no atributo label na linha 7). Os componentes filhos estão presentes nas linhas 8 e 9 respectivamente, estes componentes filhos conforme já explicado são componentes nativos do JSF e não criados a parte. Estes componentes filhos são componentes para a inserção de dados, é o componente inputtext do JSF e conforme a linha 8 é feito a ligação dos dados que serão inseridos com o atributo login e senha do backing bean validaloginbean. Finalmente, nas linhas 12 até 15 é inserido um botão (componente commandbutton) para ser feito o envio dos dados contidos no formulário para o método validalogin do backing bean validaloginbean, este método irá conter toda a lógica de verificação do login do usuário, informando se o mesmo é válido ou inválido e redirecionando para as páginas necessárias a aplicação. Segue na figura a exibição do conteúdo que o componente gera na página HTML final no browser do cliente.

43 32 Figura Conteúdo do componente gerado no browser do cliente Conforme mostra a figura 5.5.1, o componente gera um formulário para inserir um login, esse formulário não possui um bom layout, sendo que só renderiza os componentes HTML sem nenhuma formatação, mas em cima do que foi criado poderia-se criar uma estrutura para a inserção de CSS no próprio componente, ou o desenvolvedor criar um CSS para o conteúdo HTML que o componente gera, melhorando assim o layout do formulário gerado pelo componente. Estas são as etapas necessárias para o desenvolvimento e utilização de um componente simples do JSF, existem muitos outros recursos que o JSF possui para a criação de componentes, foi abordado apenas os recursos básicos e fundamentais para criação de um componente de interface gráfica com o usuário. Conforme Schalk (2007), antes de começar o desenvolvimento de novos componentes JSF, é necessário realizar uma pesquisa em quando, onde e em que nível o desenvolvimento dos componentes é necessário. Muitas vezes, o desenvolvedor pode apenas necessitar customizar um sub-componente específico, como um novo método de validação, não precisando construir um novo componente por inteiro. Pode-se encontrar vários componentes prontos e implementações prontas em projetos específicos free (como por exemplo o MyFaces (ASF, 2007c)).

44 33 6. TAPESTRY Assim como o JSF, o Tapestry também é um framework baseado em componentes para o desenvolvimento web, mas é claro que possui características diferentes. É um framework open source e utiliza a tecnologia Java (JEE) para sua implementação, portanto, é um framework que pode ser utilizado em qualquer sistema operacional que possuir a JVM. Um dos protótipos desenvolvidos neste trabalho utiliza este framework para seu desenvolvimento. Como o Tapestry utiliza o JEE, uma aplicação Tapestry pode também ser considerada uma aplicação construída com servlets. Conforme Ship (2004), o Tapestry é uma camada entre o Java servlet container e uma aplicação Tapestry, não é um servidor independente, é uma extensão para os servlets e trabalha juntamente com servlets containers (como por exemplo o Apache Tomcat) ou servidores de aplicação (como o JBoss e BEA WebLogic) que possuem incluso um servlet container. O fluxo de aplicações deste framework seguem o padrão do ciclo de uma requisição conforme já explicado (figura 3.1), ou seja, uma requisição é recebida, o processamento desta requisição é feito pelo servidor web e uma resposta é retornada para o usuário, ou mais precisamente, para o navegador que o usuário esta utilizando. As aplicações construídas com o Tapestry consistem em páginas que são construídas para componentes reutilizáveis. A aplicação opera em um servidor de aplicação, para o servidor de aplicações, a aplicação é apenas outro servlet. Aplicações web são tipicamente implementadas em termos por três camadas: A camada de apresentação, que é responsável por receber requisições HTTP e construir como resposta páginas HTML. A camada de aplicação, responsável por toda a lógica de negócio (que eventualmente são implementadas utilizando a tecnologia EJB). A camada de banco de dados, que é responsável para o armazenamento, consultas e alterações no banco de dados referente à aplicação. O Tapestry trata a camada de apresentação de uma aplicação web, portanto o Tapestry é responsável pelo tratamento das informações para o usuário final (utilização do HTML), basicamente como preenchimento de um formulário ou o click em um determinado link. No geral o Tapestry não trata a camada de aplicação e conseqüentemente a lógica de negócio e não trata a camada de banco de dados. Mas nada impede de integrar outras tecnologias juntamente com o Tapestry, como EJB para o tratamento da lógica de negócio ou o Hibernate (Hibernate, 2007) para a persistência no banco de dados, obtendo com esta integração de frameworks específicos, uma aplicação web mais robusta e produtiva. Com a utilização do Tapestry de acordo com Ship (2004), deve ser mais fácil ser feita a coisa certa do que ser feita a coisa errada. O Tapestry permite que se evite a utilização de padrões ruins no desenvolvimento de aplicações web, deve-se obter como resultado final uma aplicação robusta, escalável e de fácil manutenção, não só porque o Tapestry permite isto, mas porque o Tapestry deixa estas qualidades mais visíveis e mais simples de serem seguidas. No desenvolvimento de aplicações web, é necessário uma boa estrutura para se desenvolver, o que pode ser desenvolvido por cada desenvolvedor, mas esta liberdade de criação de uma estrutura pode não ser uma boa decisão, pois tornará a estrutura específica de um desenvolvedor (ou de uma empresa), pode deixar de implementar alguns conceitos de engenharia que podem oferecer um alto risco para o sistema, pode dificultar a integração com

45 34 outros sistemas, sendo que a estrutura utilizada é específica e não conhecida por outros sistemas, entre outras dificuldades. Caso uma determinada empresa (ou desenvolvedor) realmente necessite de uma estrutura específica, esta deverá ser desenvolvida e implementada, mas para se tornar uma boa estrutura, que não ofereça os riscos mencionados, pode consumir uma grande quantidade de tempo (o que muitas vezes é inviável). O Tapestry pode ser uma das alternativas para o preenchimento desta estrutura, sendo um framework para ser utilizado para a camada de apresentação do sistema. Segue na figura 6.1 como o Tapestry é formado basicamente no ponto de vista de um servidor de aplicação web. Figura Estrutura básica de uma aplicação Tapestry em um servidor de aplicações (SHIP, 2004) O Tapestry possui as camadas de apresentação, aplicação e banco conforme já explicado cada uma delas e como se pode observar na figura 6.1, o framework esta contido em um servidor de aplicações web, ou seja, é totalmente dependente deste servidor (este servidor podendo ser o Tomcat por exemplo), é o servidor que controla toda a aplicação. E como também é ilustrado, uma aplicação Tapestry possui suas respectivas páginas e estas fazem acesso aos seus componentes, estes podendo possuir outros componentes filhos ou sub componentes.

46 Estrutura Uma aplicação Tapestry é composta por um conjunto de páginas que são compostas de componentes. Cada página é construída pela combinação de três artefatos: uma página HTML (onde o usuário irá interagir), uma especificação desta página (que é um arquivo XML) e uma classe Java (responsável pela lógica) referente a esta página. Uma página possui um específico e único nome e este nome é utilizado para a localização da especificação da página, portanto a página HTML e sua especificação devem ter o mesmo nome. Segue um exemplo que utiliza os três artefatos utilizados por uma página Tapestry. O exemplo será uma página com um link, que quando o usuário clicar neste link, será invocado um determinado método da classe Java referente à página em questão. Assim como o JSF, é necessário configurar o Tapestry e seus respectivos servlets essenciais no arquivo de configuração do container web, que no caso do Tomcat é o web.xml. Após ser feita esta configuração (e algumas outras, dependendo do ambiente desejado), o framework esta pronto para ser utilizado. O exemplo será composto por: Página HTML Uma página HTML que é a página que o usuário visualizará e interagirá, esta página será denominada de TesteTapestry.html. Uma especificação desta página, que é um arquivo XML com determinadas configurações de componentes utilizados na página. Este arquivo de especificação deve possuir o mesmo nome da página ao qual ele será referente e deve possuir a extensão.page, portanto o arquivo será denominado de TesteTapestry.page. E por último a classe Java desta página, esta classe que será responsável por alguma lógica que possa ser implementada, podendo também redirecionar para outras páginas por exemplo, não se restringindo somente a ser uma classe com lógica de negócio. A classe não precisa necessariamente possuir o mesmo nome da página, mas para manter um padrão, a classe será denominada de TesteTapestry.java. A página HTML será simples, apenas conterá o link para o usuário clicar. 1. <html title="login"> 2. <head></head> 3. <body> 4. <a href="#" 5. jwcid="testelink" > 6. Clique para incovar o método 'imprime' 7. </a> 8. </body> 9. </html> Exemplo Conforme o exemplo 6.1.1, a página contém uma boa parte de comandos HTML puro.

47 36 Na linha 5 encontra-se a identificação do componente Tapestry, que no arquivo de especificação da página será tratado e na linha 6, encontra-se o label do link, o texto que o usuário deverá clicar para executar o método imprime da classe Java da página. Página de especificação Conforme já explicado a página HTML deve conter uma página de especificação, que é onde estarão apontados os componentes e a classe Java da página. Segue a página de especificação do exemplo, a TesteTapestry.page: 1. <?xml version="1.0" encoding="utf-8"?> 2. <!DOCTYPE page-specification PUBLIC 3. "-//Apache Software Foundation//Tapestry Specification 4.0//EN" 4. " <page-specification class="testetapestry"> 7. <component id="testelink" type="directlink"> 8. <binding name="listener" value="listener:imprime" /> 9. </component> 10. </page-specification> Exemplo Como se pode observar no exemplo 6.1.2, o arquivo de especificação da página é um arquivo XML, conforme sua configuração (linha 1). Neste arquivo serão configurados os componentes que serão utilizados na página e é especificado qual será a classe Java utilizada nesta página. Na linha 6, a tag <page-specification class> indica qual será a classe Java da página, que no exemplo será a TesteTapestry.java. Na linha 7 é indicado através da tag <component> qual componente será o campo que foi inserido na página HTML no exemplo (linha 5), o atributo id da tag <component> é o mesmo que o atributo jwcid da página HTML, o atributo type indica qual o tipo de componente será inserido na página HTML, no exemplo será inserido o componente DirectLink (componente do Tapestry responsável por inserir um link na página HTML juntamente com suas configurações necessárias), e finalmente na linha 8, através da tag <binding>, é definido qual será a ação que será executada ao clicar no link, é utilizado o atributo listener (tag value) para indicar qual será a ação, ou melhor explicando, qual será o método da classe Java da página que deverá ser executado após o clique no link, no exemplo o método a ser executado será o imprime, portanto na tag value encontra-se listener:imprime. Classe Java Por último é necessário a classe Java da página que conterá o método imprime que será executado. A classe será denominada por TesteTapestry.java. Uma classe de uma página possui várias responsabilidades definidas pelo framework, incluindo a de agir como um container para outros componentes. Segue a classe do exemplo: 1. public abstract class TesteTapestry extends BasePage 2. { 3. public void imprime(irequestcycle cycle) 4. { 5. System.out.println("Método imprime executado com sucesso!"); 6. } 7. } Exemplo 6.1.3

48 37 Na linha 1 do exemplo 6.1.3, se pode observar que a classe TesteTapestry estende a classe BasePage do framework que é a responsável pelo tratamento de classes de páginas HTML. Na linha 3 encontra-se o método que será executado ao clicar no link da página HTML, o método imprime. O método deve receber como parâmetro um objeto do tipo IRequestCycle, este sendo uma interface Java do framework responsável pelo armazenamento de informações referente a requisição corrente, através deste objeto é que o framework recupera a página ativa no momento e faz a lógica necessária para ser realizada a renderização da resposta que é enviada à máquina cliente. O método imprime apenas fará a impressão do texto Método imprime executado com sucesso! na saída padrão do sistema. Portanto este exemplo construirá uma página HTML contendo um link sobre o texto Clique para incovar o método 'imprime' que ao usuário clicar, será impresso na saída padrão o texto Método imprime executado com sucesso!. Foram utilizados no exemplo os três principais artefatos utilizados por uma página do Tapestry. A página HTML, a especificação da página e a classe Java desta página. Além destes recursos mostrados, existem muitos outros no Tapestry, como por exemplo, o uso de application objects (que são objetos utilizados na aplicação com um escopo definido, este podendo ser sessão ou aplicação), validação de formulários, callbacks (recurso para a exibição de uma determinada página que não pode ser exibida anteriormente, por exemplo, o usuário tenta acessar uma página da aplicação sem estar logado, neste caso será feito o redirecionamento para a página de login e após este ser efetuado, através do callback, a página anterior que o acesso não foi permitido é exibida), entre outros, que segundo Martins (2007), o domínio é essencial para a utilização do Tapestry em aplicações reais. 6.2 Ciclo de processos no Tapestry Até o que foi mostrado agora, é possível desenvolver algumas aplicações simples com o Tapestry, mas o framework aborda muito mais recursos dos que os básicos mostrados até aqui. Neste capítulo será mostrado como o Tapestry trabalha internamente para o tratamento dos processos. O Tapestry no geral trata o ciclo de requisições e respostas. Focando no tratamento de requisições, ou seja, um pedido vindo do usuário que posteriormente será enviado uma resposta, o framework trata da seguinte maneira: O Tapestry faz a leitura e realiza um cachê das especificações das páginas (os aquivos de extensão page que cada página HTML possui), de especificações de componentes e moldes de componentes; Cria instâncias das páginas; Faz o gerenciamento dos estados do lado servidor da aplicação, incluindo propriedades de páginas persistentes; Localiza textos e imagens contidas na página; Interpreta requisições recebidas e envia estas para objetos e métodos devidos. Segue na tabela os objetos que o Tapestry possui para realizar o tratamento de requisições recebidas pelo cliente.

49 38 Tabela Objeto Servlet da Aplicação Engine Engine Service Contexto de Requisição Ciclo da Requisição Gravador de Página Fonte da Página Carregador de Páginas Descrição É uma ponte entre a API do Servlet e o Tapestry. Atua como um cubo central para o processamento da requisição, gerencia o estado do lado servidor e faz acesso a subsistemas do Tapestry. Constrói e interpreta URL s para operações específicas do Tapestry. Cria uma camada sobre os objetos da API do Servlet, como por exemplo o HttpServletRequest e HttpSession. Coordena o processamento de uma única requisição, um cachê temporário para instâncias de páginas. Gerencia a persistência de propriedades de uma única página, move dados entre as propriedades das páginas e o objeto HttpSession. Gerencia o pool do objeto utilizado pelo ciclo da requisição para obter instâncias de páginas. Cria e configura a instâncias de novas páginas conforme necessário. Conforme Ship (2004), uma das razões que escrever servlets é mais envolvente que escrever a maioria de outras aplicações Java é que os servlets operam em um ambiente complicado, o ambiente web, um único servlet deve tratar várias requisições simultaneamente, onde são utilizadas as threads para fazer o tratamento simultâneo das requisições. A probabilidade de aparecer bugs somente quando a aplicação é carregada com uma grande sobrecarga é freqüente, e estes bugs proporcionam grandes testes, até mesmo em produção, onde depurar a aplicação é mais difícil, isso quando possível. A maioria das aplicações web desenvolvidas utilizando JEE, sem a utilização específica de um framework, possui vários servlets, cada um responsável por uma operação diferente. No Tapestry, toda a aplicação possui apenas um servlet denominado de Servlet da Aplicação, este servlet recebe várias requisições, uma vez que vários usuários podem acessar a aplicação ao mesmo tempo. O tratamento destas requisições são feitas em threads separadas, ficando assim um processo para cada requisição e sendo possível através das threads tratar mais que uma requisição simultaneamente. O Servlet da Aplicação é contido e tratado no Tapestry, portanto não é necessário o desenvolvedor utilizar em alguma classe Java da aplicação este servlet, no geral o desenvolvedor não faz a utilização direta de servlets utilizando o Tapestry. Toda aplicação web possui o tratamento que é feito no lado servidor, onde praticamente toda lógica de negócio e persistência com o banco de dados é feita (uma exceção seria uma lógica implementada em JavaScript que é interpretada no browser do cliente, não ficando no lado servidor e sim no lado cliente). Geralmente a aplicação possui um estado de informação em transição na sessão do usuário, em um determinado acesso à aplicação. Na tabela segue os principais estados do lado servidor de uma aplicação utilizando o Tapestry. Tabela Tipo API do Servlet Tapestry Bean de uma JSP com escopo de página ou de requisição; Variável temporária utilizada na renderização de uma resposta. Variável local de uma JSP Página ou propriedade de um componente

50 39 Dados específicos do cliente, disponíveis em requisições posteriores. Dados não específicos do cliente, disponíveis em requisições posteriores. (com utilização de código Java (scriptlet)); Atributo HttpServletRequest. Atributo HttpSession; Cookie HTTP. Atributo ServletContext; Variável estática. Página persistente ou propriedade de componente. Objeto do tipo Visit. Objeto global ou propriedade de objeto global. Dados de longo termo (sobrevive em qualquer sessão única de usuário) HTTP cookie. HTTP cookie. 6.3 Componentes no Tapestry A importância de componentes em um framework já foi mencionado, bem como os benefícios que a utilização destes proporciona para a aplicação, como a qualidade, a facilidade na manutenção e o aumento de produtividade no desenvolvimento desta aplicação, uma vez que os componentes são reutilizáveis, evitando o retrabalho em trechos na aplicação que devem executar uma mesma tarefa ou obter um mesmo resultado. Segundo Ship (2004), a criação de componentes customizáveis para uma aplicação e a reutilização destes componentes em diferentes páginas ou até mesmo em aplicações distintas, proporciona um impulso massivo para a produtividade dos desenvolvedores, porque reduz a quantidade de código Java a moldes HTML que teriam que ser escritos. Também traz uma melhora robusta para a aplicação evitando uma quantidade maior de testes; é utilizado o mesmo componente em diferentes lugares. Menos código sempre se traduz a menos bugs. Um componente no Tapestry é composto por: Se necessário, um template do componente; A especificação do componente; Usualmente a criação de uma classe Java para o componente. Obs.: Um componente pode não possuir um template, mas sempre deve possuir uma especificação. A especificação do componente é criada no diretório WEB-INF do servidor de aplicações (Tomcat), é um arquivo com a extensão jwc e deve possuir o mesmo nome do componente que será utilizado na página HTML. A classe Java do componente esta especificada neste arquivo com a extensão jwc do componente.

51 40 Quando um template de uma página ou uma determinada especificação referencia um componente, o Tapestry deve determinar como será feita uma instância deste componente na aplicação, sendo parte especificamente da página em questão. O primeiro passo que o framework realiza é localizar a especificação do componente (assim como as páginas possuem suas especificações, que é o arquivo com extensão page que toda página possui, os componentes possuem o arquivo com extensão jwc sendo sua especificação) para que o mesmo seja instanciado. Após ter processado a especificação do componente e instanciado o mesmo, o Tapestry irá localizar e analisar o template HTML referente ao componente. A figura ilustra este processo explicado que o Tapestry realiza quando se utiliza um componente. Figura Estrutura de execução de componentes no Tapestry (SHIP, 2004) 6.4 Exemplo de criação de componente Para exemplificar a criação de componentes no Tapestry, será desenvolvido a seguir um componente para a construção de um formulário de login, assim como foi feito no JSF. O componente possuirá: Arquivo de especificação (extensão jwc); Classe Java para realizar a lógica necessária e criar o código HTML que será retornado para o browser do cliente. Utilização do componente em uma página HTML.

52 41 Arquivo de especificação: No arquivo de especificação do componente são mencionados os atributos que o componente receberá na página HTML, a sua classe Java e outras informações, mas para o exemplo será especificado um atributo e a classe Java. O atributo do componente será o label que o desenvolvedor irá especificar na página HTML e que o formulário de login exibirá no browser, podendo ser o título do formulário. No exemplo encontra-se a especificação do componente. 1. <?xml version="1.0"?> 2. <!DOCTYPE component-specification PUBLIC 3. "-//Apache Software Foundation//Tapestry Specification 4.0//EN" 4. " <component-specification class="exemplocomponente.logincomponente "> 7. <parameter name="label"/> 8. </component-specification> Exemplo Conforme o exemplo 6.4.1, o arquivo de especificação do componente é um arquivo XML, nas primeiras linhas do exemplo é citado a versão do XML que será utilizada, nas linhas 2 até 4 é especificado o tipo do documento para a interpretação do framework, neste caso esta sendo utilizado o Tapestry 4.0 e por isso foi especificado a versão do Tapestry, portanto de acordo com a versão utilizada, o cabeçalho do documento deverá conter um conteúdo específico (assim com também é feito nos templates das páginas HTML, os arquivos com extensão page). A primeira tarefa feita na especificação do componente, foi indicar qual a classe Java que pertencerá ao componente, que conforme a linha 6, a classe a ser utilizada será a classe LoginComponente que se encontra no pacote exemplocomponente. Classe Java: Para componentes que não possuem nenhum template que é o caso do componente que será desenvolvido neste exemplo, é necessário que este seja subclasse da classe AbstractComponent e o componente será inteiramente executado em sua respectiva classe Java, sem template (mesmo o componente não possuindo template é necessário que possua uma especificação, esta foi criada no exemplo 6.4.1). Outra particularidade dos componentes que estendem a classe AbstractComponent, é que a renderização do código HTML que será enviado para o cliente, é feita na classe Java, através do método rendercomponent(), este sendo invocado automaticamente pelo framework, não sendo necessário que o desenvolvedor invoque este método através de uma classe. A classe Java do componente é declarada da seguinte forma: public abstract class LoginComponente extends AbstractComponent O nome da classe é LoginComponente e conforme mencionado, deve ser subclasse da classe AbstractComponent, portanto estende-se a mesma. Segue no exemplo a implementação do método rendercomponent. 1. protected void rendercomponent(imarkupwriter writer, IRequestCycle cycle) 2. {

53 42 3. writer.begin("table"); 4. writer.begin("tr"); 5. writer.begin("td"); 6. writer.print(getlabel()); 7. writer.end("td"); 8. writer.end("tr"); for(int i=0; i<this.getbodycount(); i++) 11. { 12. if(this.getbody()[i] instanceof TextField) 13. { 14. writer.begin("tr"); 15. writer.begin("td"); 16. cycle.getresponsebuilder().render(writer, this.getbody()[i], cycle); 17. writer.end("td"); 18. writer.end("tr"); 19. } 20. } writer.end("table"); 23. } Exemplo Conforme na linha 1 do exemplo 6.4.2, os parâmetros necessários para o método redercomponent são: um objeto do tipo IMarkutMarker e um objeto do tipo IRequestCycle. O objeto do tipo ImarkutMarker é responsável por produzir a saída do código, contém métodos responsáveis para a impressão de códigos HTML para serem enviados para o cliente. Já o objeto do tipo IRequestCycle é responsável por gerenciar o ciclo da requisição que esta sendo tratada no momento. Como serão escritos códigos HTML na resposta que será enviada para o cliente, o Tapestry possui alguns métodos que facilitam na escrita destes códigos. Uma tag HTML é aberta com <...> e fechada com </>, mas não é necessário o desenvolvedor sempre utilizar estes caracteres para abrir ou fechar uma tag HTML, o método begin já realiza a tarefa da abertura correta de uma determinada tag HTML e o método end realiza a tarefa de fechar sua respectiva tag. Por exemplo, para escrever o seguinte código HTML: <td> Teste de Tag </td> Seria necessário utilizar os método begin e end do framework ficando da seguinte forma: 1. writer.begin("td"); 2. writer.print( Teste de Tag ); 3. writer.end("td"); Na linha 1, é feita a abertura da tag td, na segunda linha é escrito o texto Teste de Tag (sendo que o método print escreve um determinado texto HTML) e finalmente na linha 3 é fechada a tag td.

54 43 Voltando ao exemplo 6.4.2, da linha 3 até a linha 8 é feita a escrita do título da tabela que será gerada no HTML que será exibida no browser do cliente, sendo que na linha 6 onde será escrito o título, é recebido o retorno do método getlabel que conterá o valor mencionado na página pelo desenvolvedor, através do atributo label, fazendo com que o título não seja estático e sim de acordo com o que o desenvolvedor definir. Da linha 10 até a 20, é feito um laço para renderizar os componentes filhos, que neste caso serão dois, o campo para ser feita à entrada do login e o campo para a entrada da senha. Na linha 12 é verificado se o componente que esta sendo verificado no momento do laço é um TextField, na teoria eram para ser somente dois componentes filhos do tipo TextField (campo de login e senha), mas o framework adiciona alguns componente de outros tipos, por isso foi necessária a validação do tipo. Na linha 16 é que é feita a rederização do componente filho, este possuindo seu código HTML específico. E finalmente na linha 22 é fechada a tag table que foi iniciada na linha 3. Esse processo faz com que seja renderizada uma tabela HTML no browser do usuário. A figura mostra através de um diagrama UML (Unified Modeling Language) a hierarquia das classes disponíveis para a criação de componentes no Tapestry. Figura UML com as classes para a criação de componentes no Tapestry (ASF, 2007d) Utilização do componente em uma página HTML: O componente foi criado, agora será mostrado com deve ser feita a utilização deste componente em uma página HTML.

55 44 Conforme já explicado, uma página no Tapestry é definida pelos artefatos: especificação da página (que é o arquivo XML que pode conter informações referentes aos componentes utilizados na página e indica onde esta localizada e qual é a classe Java da respectiva página), a classe Java que fará o controle dos eventos realizados pelo usuário na página e que também faz o redirecionamento para outras páginas e por último a própria página HTML, onde são utilizados os componentes e os códigos HTML puros, que não terão alterações pelo framework. O exemplo que segue, mostra como é feito o arquivo XML com a especificação da página. 1. <?xml version="1.0" encoding="utf-8"?> 2. <!DOCTYPE page-specification PUBLIC 3. "-//Apache Software Foundation//Tapestry Specification 4.0//EN" 4. " <page-specification class="testecomponente"> 7. </page-specification> Exemplo Conforme o exemplo 6.4.3, da linha 1 até a linha 4, são feitas as configurações necessárias para o documento XML, e é indicado qual a versão que esta sendo utilizada do Tapestry para que o framework interprete corretamente. Nas linhas 6 e 7, são definidas as propriedades da página, como a página será simples, contendo apenas o componente criado, não foi declarado nenhum atributo e nenhuma propriedade específica para página, portanto só foi necessário indicar qual é a classe Java da página em questão, que neste exemplo, será a classe TesteComponente que se encontra o pacote default, pois este não foi especificado. Após ser feita a especificação da página, é feita a própria página, esta já contendo a extensão html. A página do exemplo é mostrada no exemplo <html title="login"> 2. <head> 3. <title>.:: Teste do componente de Login ::.</title> 4. </head> 5. <body> 6. <form jwcid="@form" listener="ognl:listeners.validalogin"> 7. <input jwcid="@login" label=".::entre com os dados para o Login::."> 8. <input jwcid="@textfield" value="ognl:login" size="30"/> 9. <input jwcid="@textfield" value="ognl:senha" size="30"/> 10. </input> 11. <br> 12. <input type="submit" value="login"/> 13. </form> 14. </body> 15. </html> Exemplo Conforme mostra o exemplo 6.4.4, são utilizadas tags puras do HTML, como o <title> utilizado na linha 3 e o próprio <form> na linha 6. Os componentes do Tapestry são identificados na página HTML através do atributo jwcid que significa Java Web Component ID.

56 45 O jwcid é utilizado na linha 6, indicando que será um formulário do Tapestry, ou seja, um componente do framework que gera o código HTML representando um formulário, o componente criado é utilizado na linha 7, onde indica-se que o componente é o login através da tag jwcid, o framework recupera esta identificação e vai buscar a especificação do componente que foi criada no exemplo e possui o nome login.jwc e partir deste ponto são feitos os procedimentos internos do framework para a geração do código HTML que o componente é responsável por criar, este código foi criado na classe Java do componente, no exemplo Nas linhas 8 e 9, são inseridos os componentes filhos (o campo para a inserção do login e para a inserção da senha), estes componentes filhos são do tipo TextField que é um componente nativo do framework e não foi criado, é utilizado para a entrada de texto, os campos foram relacionados com os atributos login e senha da classe Java da página, através do atributo value, para posteriormente serem utilizados para a validação do login. E por último é criado um botão de submit para o formulário, onde será invocado o método validalogin (especificado na linha 6, através do atributo listener) e este método conterá as validações necessárias para verificar se o login inserido pelo usuário é válido ou inválido, podendo direcionar para uma determinada página a aplicação de acordo com suas validações. A figura mostra como é gerado o componente no browser do cliente. Figura Conteúdo do componente gerado no browser do cliente O componente gerou o formulário mostrado na figura para a inserção do login sem nenhuma formatação, mas pode ser feita a inserção de CSS (Cascading Style Sheets) no próprio componente ou na própria página HTML para deixar o formulário com uma melhor aparência. Segundo ASF (2007d), os componentes do Tapestry podem ser simples ou complexos. Eles podem ser específicos para uma única aplicação ou para uma aplicação completamente genérica. Podem também ser uma parte de uma aplicação, ou podem ser empacotados em uma biblioteca. Os componentes nativos do framework não são especiais em nenhum ponto, não possuem acesso a nenhuma API diferente ou alguma performance especial, qualquer tarefa que os componentes nativos podem realizar, os componentes criados a parte também podem realizar.

57 46 7. DESCRIÇÃO DO PROTÓTIPO Um dos objetivos deste trabalho é a construção de dois protótipos de uma aplicação web utilizando dois frameworks baseados em componentes em seu desenvolvimento. Hoje em dia, a maioria das empresas possuem um sistema para o controle de seus funcionários, tendo um acesso prático aos dados de seus funcionários, como o endereço, o cargo ou o salário. Umas das alternativas para tornar este sistema ou esta aplicação que é responsável pelo controle dos dados dos funcionários, mais prática, seria o funcionário responsável pelo acesso à aplicação poder fazer o cadastro, alteração ou consulta dos funcionários de qualquer lugar, não ficando restrito a estar necessariamente na empresa onde a aplicação se encontra instalada. Para obter esta flexibilidade, pode-se criar uma aplicação web para esse controle dos funcionários, podendo assim o usuário da aplicação acessar a mesma de qualquer lugar, precisando apenas de um navegador e uma conexão com a internet. Portanto o funcionário responsável pela utilização do sistema poderia acessar a aplicação da empresa de onde ele estivesse, podendo utilizar até um notebook que necessitaria apenas um navegador e conexão com a internet. O protótipo desenvolvido pelo trabalho será uma aplicação web para o controle de funcionários de uma empresa. Para saber os dados de um determinado funcionário da empresa, o usuário apenas necessitaria ter um login para acesso ao sistema (e obviamente um navegador e conexão com a internet, conforme explicado). Fazendo com que o usuário (que pode ser um funcionário do RH da empresa) para saber a situação de um funcionário junto à empresa, como por exemplo o endereço ou o telefone, não fique restrito a acessar a aplicação somente do computador ou da rede interna da empresa. Este protótipo possui as seguintes funcionalidades: O sistema possuirá um usuário autorizado a utilizar o sistema, sendo portanto o administrador do sistema, este possuindo um login. Somente este usuário cadastrado terá acesso a aplicação. Cadastro de funcionários, onde serão cadastrados novos funcionários com seus respectivos dados, como nome, endereço, telefone, entre outros dados. Alteração dos dados dos funcionários, onde o usuário do sistema poderá alterar dados de um determinado funcionário, como por exemplo, a mudança de endereço ou telefone de um funcionário. Exclusão de funcionários, caso a empresa não possua mais interesse em manter um determinado funcionário em seu histórico, o mesmo poderá ser excluído da aplicação. Para a construção deste protótipo de aplicação web para o controle de funcionários de uma empresa, serão utilizados os frameworks baseados em componentes tratados em tópicos anteriores neste trabalho, o JSF e o Tapestry. Para o armazenamento dos dados será utilizado o banco de dados MySql. Portanto serão criados dois protótipos com o mesmo propósito e as mesmas funcionalidades mencionadas anteriormente. Cada protótipo será desenvolvido com um framework diferente, um protótipo será desenvolvido utilizando o JSF e o outro protótipo utilizando o Tapestry, focando na comparação entre os dois frameworks utilizados.

58 Descrição do ambiente de teste e desenvolvimento Para o desenvolvimento de aplicações, são necessários vários requisitos, como: uma determinada linguagem para ser feito o desenvolvimento, eventualmente um framework integrado com a linguagem utilizada, uma IDE (Integrated Development Environmet) para aumentar a produtividade do desenvolvimento, podem ser necessárias determinadas configurações no computador que será utilizado e determinados requisitos de hardware para que seja possível o desenvolvimento e/ou para que seja possível executar a aplicação corretamente. No desenvolvimento dos protótipos deste trabalho foram utilizados os seguintes recursos: Computador: Processador AMD Athlon 1.10 GHz 384 MB de memória RAM Linguagem: Java 5 Framework: JSF 1.1 Tapestry Servidor de Aplicações: Apache Tomcat Banco de Dados: MySql 5.0 IDE: NetBeans 5.5 Os itens citados foram os utilizados para o desenvolvimento dos protótipos, e como se pode observar, não foi utilizado um computador potente ou tão robusto e sim um computador comum de uso pessoal que no mercado atual é considerado ultrapassado, tendo como referência o seu processador e a quantidade de memória RAM (Random Access Memory) que o mesmo dispõe, estes sendo os principais fatores no computador que influenciam na performance dos softwares utilizados. Portanto, o ideal para poder se desenvolver obtendo uma resposta de maneira eficaz e rápida do computador (e conseqüentemente dos softwares utilizados), seria utilizar um computador com configurações mais potentes, ou seja, com um processador mais rápido e principalmente com uma quantidade de memória RAM maior, tendo em vista que as ferramentas utilizadas, como por exemplo a IDE utilizada, o NetBeans, exige uma grande quantidade de memória RAM, considerando a quantidade que estava disponível que era de 352 MB de RAM. Diante destes pontos, concluísse que um computador mais potente seria uma melhor opção para obter uma maior produtividade, mas mesmo com um computador não tão potente, que foi o utilizado no desenvolvimento dos protótipos, é possível desenvolver utilizando as tecnologias/frameworks citados e que foram utilizados neste trabalho.

59 48 Os framework utilizados e que foram explicados em tópicos anteriores do trabalho, foram: o JSF, utilizando a versão 1.1 e o Tapestry, que foi utilizada a versão O servidor de aplicações utilizado foi o Tomcat , este sendo compatível com o Java 5 (podendo funcionar com outras versões, mas segundo ASF (2007b) é requerido a JRE (Java Runtime Environment) 5.0), portanto foi utilizada a versão 5 do Java para o desenvolvimento, sendo que muitos recursos não seriam possível serem utilizados pelos frameworks utilizando uma versão anterior do Java (como por exemplo as anotações que facilitam em especificações do Tapestry e que só esta disponível no Java a partir da versão 5). Para o armazenamento dos dados dos protótipos das aplicações, foi o utilizado o banco de dados MySql (MySql, 2007) em sua versão 5.0. A versão do MySql utilizada é livre, não necessitando portanto de alguma licença para a sua utilização. E para facilitar em inúmeras formas, foi utilizada a IDE NetBeans, versão 5.5, também sendo um software livre. Existem várias outras IDE s para o desenvolvimento Java para o auxílio de aplicações web, como por exemplo o Eclipse (Eclipse, 2007). 7.2 Desenvolvimento do Protótipo utilizando o JSF O protótipo desenvolvido utilizando o JSF possui as seguintes funcionalidades: Tela de login (tela inicial) para a aplicação, conforme a figura 7.2.1, onde o usuário informa o login e sua respectiva senha para o acesso à aplicação. Somente é permitido acesso a usuários cadastrados nos sistema (ao criar a base de dados do sistema, através do script SQL (Structured Query Language), é criado um usuário para acessar no sistema). Figura Tela de login do protótipo desenvolvido em JSF

60 49 Após o usuário informar um login válido, a aplicação é redirecionada para o menu principal (figura 7.2.2), onde poderão ser selecionadas as funcionalidades do sistema, como cadastro ou consulta de funcionários. Figura Menu do protótipo desenvolvido em JSF Ao lado direito do menu são exibidos o nome e a função do usuário que esta utilizando a aplicação no momento, conforme mostra a figura Foi desenvolvida também a tela para a consulta dos funcionários, onde o usuário informa o código do funcionário (conforme figura 7.2.3) e seus respectivos dados são exibidos conforme figura Ao clicar no botão Menu, volta-se ao menu da aplicação (figura 7.2.2). Figura Tela de filtro de funcionário

61 50 Ao clicar no botão Filtrar, são exibidos os dados do usuário que possui o código informado, conforme figura Figura Tela de dados do funcionário O protótipo possui também a funcionalidade para a alteração dos dados de funcionários. O usuário informa o código do funcionário que será alterado (conforme figura 7.2.5) e seus respectivos dados são exibidos conforme figura e ficam disponíveis para alterações que são efetuadas ao clicar no botão Alterar. Figura Tela de filtro do funcionário que será alterado

62 51 Ao clicar no botão Filtrar, é exibida a tela para a alteração do funcionário com o código informado, conforme mostra a figura Figura Tela de alteração do funcionário Foram realizadas algumas validações na tela de alteração, para que todos os dados sejam informados e que sejam informados em seu formato correto. Caso algum campo não esteja preenchido, é exibida uma mensagem informando que todos os campos devem ser preenchidos (figura 7.2.7) e caso algum campo estiver no formato incorreto, ou seja, campos com dados numéricos como telefone e CEP possuírem letras, é exibida uma mensagem informando que o campo deve ser numérico (figura 7.2.8). Figura Mensagem de alerta para o usuário, referente ao preenchimento dos campos Figura Mensagem de alerta para o usuário, referente ao formato dos campos

63 52 Foi desenvolvida a tela para ser realizado o cadastro de funcionários (figura 7.2.9), onde o usuário informa os dados do funcionário e salva no banco de dados da aplicação clicando no botão Cadastrar. Nesta tela de cadastro, foram feitas as mesmas validações que a tela de alteração, referente aos campos informados pelo usuário, para que todos os campos sejam preenchidos e que sejam preenchidos no formato correto, conforme mostram as figuras e Figura Tela de cadastro Outra funcionalidade do protótipo é a exclusão dos dados dos funcionários. O usuário informa o código do funcionário que será excluído do sistema (conforme figura ) e ao clicar no botão Excluír, o funcionário com o respectivo código é excluído. Figura Tela de exclusão de funcionários

64 53 Caso em uma das telas de filtro mostradas (utilizadas na consulta, alteração de exclusão de funcionários) seja informado um código que não existe, é exibida uma página informando ao usuário que o funcionário com o código informado não existe no sistema, conforme a figura Figura Página informando que o funcionário requisitado não existe no sistema Após uma operação ser realizada no sistema, ou seja, o cadastro de um funcionário ao clicar no botão Cadastrar, a alteração de um funcionário ao clicar no botão Alterar ou a exclusão de um funcionário ao clicar no botão Excluír, é exibida uma página informando ao usuário se a operação foi realizada com sucesso (figura ) ou se ocorreu algum problema durante a operação (figura ). Figura Página informando que a operação ocorreu com sucesso

65 54 Figura Página informando que a operação não foi realizada por algum erro 7.3 Desenvolvimento do Protótipo utilizando o Tapestry Assim como o protótipo desenvolvido em JSF, foi feito o desenvolvimento do mesmo protótipo, ou seja, com as mesmas as funcionalidades e visando manter a mesma aparência utilizando o Tapestry. Seguem imagens do protótipo desenvolvido utilizando o Tapestry: Tela de login (tela inicial) para a aplicação, conforme figura 7.3.1, onde o usuário informa o login e sua respectiva senha para o acesso à aplicação. Somente é permitido acesso a usuários cadastrados nos sistema (ao criar a base de dados do sistema, através de script SQL, é criado um usuário para acessar no sistema, a mesma base de dados é utilizada para os dois protótipos criados). Figura Tela de login do protótipo desenvolvido em Tapestry

66 55 Após o usuário informar um login válido, a aplicação é redirecionada para o menu principal (figura 7.3.2), onde poderão ser selecionadas as funcionalidades do sistema, como cadastro ou consulta de funcionários. Figura Menu do protótipo desenvolvido em Tapestry Ao lado direito do menu é exibido o nome e a função do usuário que esta utilizando a aplicação no momento, conforme mostra a figura Foi desenvolvida também a tela para a consulta dos funcionários, onde o usuário informa o código do funcionário (conforme figura 7.3.3) e seus respectivos dados são exibidos conforme figura E ao clicar no botão Menu, volta-se ao menu da aplicação (figura 7.3.2). Figura Tela de filtro de funcionário

67 56 Ao clicar no botão Filtrar, são exibidos os dados do usuário que possui o código informado, conforme figura Figura Tela de dados do funcionário O protótipo possui também a funcionalidade para a alteração dos dados de funcionários. O usuário informa o código do funcionário que será alterado (conforme figura 7.3.5) e seus respectivos dados são exibidos conforme figura e ficam disponíveis para alterações que são efetuadas ao clicar no botão Alterar. Figura Tela de filtro do funcionário que será alterado

68 57 Ao clicar no botão Filtrar, é exibida a tela para a alteração do funcionário com o código informado, conforme mostra a figura Figura Tela de alteração do funcionário Assim como no protótipo desenvolvido em JSF, foram realizadas algumas validações na tela de alteração, para que todos os dados sejam informados e que sejam informados em seu formato correto. Caso algum campo não esteja preenchido, é exibida uma mensagem informando que todos os campos devem ser preenchidos (figura 7.3.7) e caso algum campo estiver no formato incorreto, ou seja, campos com dados numéricos como telefone e CEP possuírem letras, é exibida uma mensagem informando que o campo deve ser numérico (figura 7.3.8). Figura Mensagem de alerta para o usuário, referente ao preenchimento dos campos

69 58 Figura Mensagem de alerta para o usuário, referente ao formato dos campos Foi desenvolvida a tela para ser realizado o cadastro de funcionários (figura 7.3.9), onde o usuário informa os dados do funcionário e salva no banco de dados da aplicação clicando no botão Cadastrar. Nesta tela de cadastro, foram feitas as mesmas validações dos campos informados pelo usuário, para que todos os campos sejam preenchidos e que sejam preenchidos no formato correto, conforme mostram as figuras e Figura Tela de cadastro

70 59 Outra funcionalidade do protótipo é a exclusão dos dados dos funcionários. O usuário informa o código do funcionário que será excluído do sistema (conforme figura ) e ao clicar no botão Excluír, o funcionário com o respectivo código é excluído. Figura Tela de exclusão de funcionários Caso em uma das telas de filtro mostradas (utilizadas na consulta, alteração de exclusão de funcionários) seja informado um código que não existe, é exibida uma página informando ao usuário que o funcionário com o código informado não existe no sistema, conforme a figura Figura Página informando que o funcionário requisitado não existe no sistema