Guilherme Augusto Peron Borges
0402028 - 8° Semestre
FRAMEWORKS
PARA O DESENVOLVIMENTO WEB
Jaguariúna
2007
Guilherme Augusto Peron Borges
0402028 - 8° 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
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
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.
BORGES, Guilherme Augusto Peron. Frameworks para o desenvolvimento web. 2007. 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.
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.
SUMÁRIO
1. INTRODUÇÃO...1 2. METODOLOGIA...3 3. APLICAÇÕES WEB ...4 4. JEE...6 4.1 Segurança...7 4.2 Componentes ...7 4.3 Aplicação em JEE...8 4.4 Servlet...94.5 Exemplo de verificação de login em JEE...10
5. JSF ...16
5.1 Internacionalização...18
5.2 Backing Beans ...19
5.3 Eventos no JSF ...20
5.4 Componentes ...22
5.5 API para desenvolvimento de componentes gráficos no JSF...22
6. TAPESTRY...33
6.1 Estrutura ...35
6.2 Ciclo de processos no Tapestry ...37
6.3 Componentes no Tapestry ...39
6.4 Exemplo de criação de componente ...40
7. DESCRIÇÃO DO PROTÓTIPO...46
7.1 Descrição do ambiente de teste e desenvolvimento ...47
7.2 Desenvolvimento do Protótipo utilizando o JSF ...48
7.3 Desenvolvimento do Protótipo utilizando o Tapestry ...54
8. COMPARAÇÃO JSF X TAPESTRY...61
8.1 Praticidade ...61
8.2 Complexidade do ambiente necessário para a utilização do framework ...62
8.3 Quantidade de componentes nativos disponíveis para utilização...63
8.4 Quantidade de componentes de terceiros disponíveis para o framework...63
8.5 Ferramentas disponíveis para a utilização do framework...64
8.6 Utilização do framework no mercado atual...66
9. CONCLUSÕES ...68 10. REFERÊNCIAS BIBLIOGRÁFICAS ...69
Lista de Figuras
Figura 3.1 - Ilustação do fluxo de aplicações web ...4
Figura 4.1 - Ilustração de dois sistemas JEE multicamadas ...6
Figura 4.3.1 - Fluxo de sistemas JEE ...8
Figura 5.1 - Nível de abstração de tecnologias utilizadas no JSF ...17
Figura 5.5.1 - Conteúdo do componente gerado no browser do cliente...32
Figura 6.1 - Estrutura básica de uma aplicação Tapestry em um servidor de aplicações ...34
Figura 6.3.1 - Estrutura de execução de componentes no Tapestry ...40
Figura 6.4.1 - UML com as classes para a criação de componentes no Tapestry ...43
Figura 6.4.2 - Conteúdo do componente gerado no browser do cliente...45
Figura 7.2.1 - Tela de login do protótipo desenvolvido em JSF ...48
Figura 7.2.2 - Menu do protótipo desenvolvido em JSF ...49
Figura 7.2.3 - Tela de filtro de funcionário ...49
Figura 7.2.4 - Tela de dados do funcionário...50
Figura 7.2.5 - Tela de filtro do funcionário que será alterado ...50
Figura 7.2.6 - Tela de alteração do funcionário...51
Figura 7.2.7 - Mensagem de alerta para o usuário, referente ao preenchimento dos campos ..51
Figura 7.2.8 - Mensagem de alerta para o usuário, referente ao formato dos campos ...51
Figura 7.2.9 - Tela de cadastro ...52
Figura 7.2.10 - Tela de exclusão de funcionários...52
Figura 7.2.11 - Página informando que o funcionário requisitado não existe no sistema...53
Figura 7.2.12 - Página informando que a operação ocorreu com sucesso...53
Figura 7.2.13 - Página informando que a operação não foi realizada por algum erro ...54
Figura 7.3.1 - Tela de login do protótipo desenvolvido em Tapestry ...54
Figura 7.3.2 - Menu do protótipo desenvolvido em Tapestry ...55
Figura 7.3.3 - Tela de filtro de funcionário ...55
Figura 7.3.4 - Tela de dados do funcionário...56
Figura 7.3.5 - Tela de filtro do funcionário que será alterado ...56
Figura 7.3.6 - Tela de alteração do funcionário...57
Figura 7.3.7 - Mensagem de alerta para o usuário, referente ao preenchimento dos campos ..57
Figura 7.3.8 - Mensagem de alerta para o usuário, referente ao formato dos campos ...58
Figura 7.3.10 - Tela de exclusão de funcionários...59
Figura 7.3.11 - Página informando que o funcionário requisitado não existe no sistema...59
Figura 7.3.12 - Página informando que a operação ocorreu com sucesso...60
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
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
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. 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).
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.
Figura 3.1 - Ilustação do fluxo de aplicações web
Conforme a figura 3.1:
• 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:
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
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 4.1 - 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
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
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:
Figura 4.3.1 - Fluxo de sistemas JEE (SUN, 2007a)
Conforme figura 4.3.1:
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).
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
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á:
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.
Páginas
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 4.5.1.
<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 4.5.1
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 4.5.2 e 4.5.3 os códigos das páginas loginValido.jsp e
loginInvalido.jsp respectivamente.
• loginValido.jsp <html> <head>
</head> <body> <b>Login válido!</b> </body> </html> Exemplo 4.5.2 • 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 4.5.3
As duas páginas (exemplo 4.5.2 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())
return true;
return false; }
Exemplo 4.5.4
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 4.5.5.
• 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 4.5.5
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 4.5.5 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
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 4.5.1.
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 ‘http://www.testeparams.com/index.html?id=1&flag=2&teste=3’, 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 e-mail.
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 4.5.6
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");
6.
7. 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. } 26. 27. dispatcher.forward(request, response); 28. } Exemplo 4.5.7
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 4.5.7. 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.
E finalmente na linha 27 são redirecionados o request e o response para a página que foi determinada pela lógica aplicada.
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
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 5.1 - 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
própria utilização do framework que é onde se consegue obter o maior nível de abstração, conforme mostrado na figura 5.1.
5.1 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 5.1.1
• Recuperação do local das mensagens:
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 5.1.1. 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
faces-config.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 5.2.1.
1. <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 5.2.1
Conforme exemplo 5.2.1, um backing bean é declarado através da tag
<managed-bean>, 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-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 5.2.2 (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 5.2.1 é teste) juntamente com o método que será executado, ficando da seguinte forma:
‘nomeDoBackingBean.nomeDoMetodo’, como se encontra no exemplo 5.2.2 na linha 4.
5.3 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
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 5.3.1
• Classe Java que será o backing bean:
1. package beans; 2.
3. public class TesteBackingBean 4. {
5. public void imprime() 6. {
7. System.out.println("Método do Backing Bean Executado!"); 8. }
9. }
Exemplo 5.3.2
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="http://java.sun.com/jsf/core" prefix="f" %> 2. <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 3. 4. <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 5.3.3
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
(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 5.3.1 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.
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íficasnecessá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.
