Desenvolvimento de Aplicações para Internet Material Apoio AOL 3

Prévia do material em texto

Deployment Descriptor (arquivo web.xml)
As aplicações Java para web funcionam em um determinado contêiner web e suas configurações e descrição de itens de funcionamento ficam situadas em um arquivo chamado Deployment Descriptor, ou descritor de implantação, em português. Ele indica ao contêiner, por exemplo, como as URLs são mapeadas para o processamento nos servlets e quais URLs exigem autenticação.
Esse arquivo é o web.xml, que fica gravado no diretório WEB-INF/ (que, por sua vez, situa-se na raiz dos arquivos do projeto), fazendo parte do padrão Servlet API para aplicações web em Java.
Como o arquivo web.xml possui várias opções que podem ser definidas, seguindo uma estrutura de formação rígida (natural de arquivos XML), existem ferramentas que apoiam o seu preenchimento. Esse é o caso do ambiente Eclipse, que oferece, em seu “Project Explorer”, um editor gráfico para auxiliar o desenvolvedor na escrita do arquivo web.xml, como pode ser visto na Figura 1.
Figura 1. Captura de tela: editor gráfico do Deployment Descriptor no ambiente Eclipse.
Conforme visto na Figura 1, o arquivo web.xml é dividido em seções, para configuração de diferentes opções sobre os recursos do servidor. Essas seções são explicadas a seguir (HUNT e LOFTUS, 2003):
Clique nos botões para saber mais
Context Parameters
+
Error Pages
+
Filter Mappings
+
Filters
+
Listeners
+
References
+
Servlet Mappings
+
Servlets
+
Welcome Pages
+
Note que a opção e a edição gráfica do arquivo web.xml somente aparece para o desenvolvedor se o projeto no Eclipse for do tipo “Dynamic Web Project”, pois é nele que estão habilitados os recursos do pacote Web Tools Platform (WTP).
Para visualizar o arquivo gerado a partir dessas configurações, é necessário cIicar com o botão direito do mouse no nome do projeto, selecionar "Java EE Tools" e, em seguida, clicar em "Generate Deployment Descriptor Stub".
Para fins didáticos, visando a exemplificar itens comuns em uma aplicação que usa banco de dados, e com uma área restrita que necessita de senha, apresentamos o arquivo web.xml gerado, com 36 linhas, que pode ser visto no Código-fonte 1. Ou seja, algumas configurações e recursos possíveis no Deployment Descriptor são opcionais, devendo seus possíveis itens de preenchimento ser utilizados de acordo com a demanda da aplicação.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
 <display-name>exemplo1</display-name>
 <description>Exemplo para ensino de configuração</description>
 <welcome-file-list>
 <welcome-file>index.jsp</welcome-file>
 </welcome-file-list>
 <context-param>
 <param-name>bd-user</param-name>
 <param-value>usuarioexemplo</param-value>
 </context-param>
 <context-param>
 <param-name>bd-password</param-name>
 <param-value>senhaexemplo</param-value>
 </context-param>
 <context-param>
 <param-name>bd-URL</param-name>
 <param-value>jdbc:mysql://localhost:3306</param-value>
 </context-param>
 <filter>
 <filter-name>AuthenticationFilter</filter-name>
 <filter-class>mypackage.AuthenticationFilter</filter-class>
 </filter>
 <filter-mapping>
 <filter-name>AuthenticationFilter</filter-name>
 <url-pattern>/area-restrita/*</url-pattern>
 </filter-mapping>
 <error-page>
 <error-code>400</error-code>
 <location>/errors/page-not-found.jsp</location>
 </error-page>
 <error-page>
 <error-code>500</error-code>
 <location>/errors/error-500.jsp</location>
 </error-page>
</web-app>
Código-fonte 1. Exemplo de arquivo web.xml.
Na linha 1 de nosso exemplo, temos a versão do XML usada (1.0) e sua codificação (a UTF-8 ou 8-bit Unicode, como também é conhecida); já na linha 2, o esquema de marcação do tipo XMLSchema tem sua URL indicada. Na linha 3, é definido o nome da aplicação, que nesse caso é “exemplo1”, seguido da respectiva descrição. Das linhas 5 a 7, é possível visualizar a primeira página definida para a aplicação, a “index.jsp”.
Já nas linhas de 8 a 19 são declarados três parâmetros de contexto e seus respectivos valores, que, por definição, podem ser acessados por códigos de toda a aplicação. Em nosso caso, esses parâmetros são as informações para conexão em um servidor de banco de dados.
Nas linhas de 20 a 23, é indicado um filtro, chamado “AuthenticationFilter”, com seu respectivo endereço de acesso de classe. Note que esse endereço se inicia pelo nome do pacote escolhido para utilização no momento da criação do projeto no Eclipse.
Esse filtro foi criado para funcionar como um verificador de autenticação de sessão para as páginas mapeadas no padrão de URL, indicado na linha 26. O padrão de URL “/area-restrita/*” sinaliza ao servidor que todas as páginas dentro da pasta “area-restrita”, antes de serem processadas, devem chamar o filtro, que verifica se há sessão válida ou não.
A sintaxe para formação do padrão de URL é própria e definida na especificação da Servlet API (ORACLE, 2017b), a saber:
· Uma string de texto começando com "/" e sendo finalizada por "/*" indica que todas as URLs que contenham esse caminho sejam aplicadas ao filtro;
· Uma string de texto começando com "*." significa o mapeamento de extensões de arquivo;
· Uma string de texto vazia "", um padrão especial para a raiz do contexto, do tipo http://host:port/<context-root>/;
· Uma string contendo somente "/" indica o servlet-padrão da aplicação;
· Todas as outras strings de texto são para casamento exato do padrão, ou seja, para uma URL única e específica.
Por fim, nas linhas de 28 a 35, há indicação de que o desenvolvedor utilizará páginas de erro personalizadas: uma para quando o servidor retornar o erro 404, que é o de página não encontrada, e outra, para quando retornar o erro 500, que é o Internal Server Error (erro interno de servidor).
DICA
Vale lembrar que as marcações em XML, diferentemente do HTML, são case sensitive, ou seja, há diferenciação entre letras maiúsculas e minúsculas. Assim, recomendamos (e normalmente é assim que é feito na prática) que todas as marcações sejam feitas com letra minúscula, ou lower case, no arquivo web.xml.
Um aspecto importante de evolução do modelo de programação da plataforma Java EE, a partir de sua versão 5, foi a introdução de anotações de metadados nas classes. As anotações funcionam com comandos iniciados pelo caractere @ e simplificam o processo de desenvolvimento do aplicativo, permitindo que um desenvolvedor especifique na própria classe Java as configurações desejadas.
As anotações, então, são uma alternativa aos descritores de implantação, sendo que, agora, os descritores padrão application.xml e web.xml são opcionais.
Um exemplo de anotação é feito com o comando @WebServlet, inserido dentro de uma classe Servidor para declarar um servlet. Isso pode ser visto no Código-fonte 2, apresentado a seguir.
1.	@WebServlet(value="/teste", name="ServletTeste")
2.	public class ServletTeste extends javax.servlet.http.HttpServlet {
3.	 //...
4.	}
Código-fonte 2. Exemplo de uso da anotação @WebServlet.
Com esse exemplo, foi possível criar um servlet e configurá-lo para ser utilizado em uma URL parecida com a seguinte, sem ter que listá-lo no arquivo web.xml:
http://localhost:8080/contexto/ServletTeste/
Escopos de aplicação, sessão, requisição e página
O conceito de escopo em desenvolvimento de software se refere a um delimitador de espaço e tempo em que é possível acessar um determinado recurso, que geralmente é uma variável ou objeto. As aplicações Java para web possuem quatro escopos possíveis: o de aplicação, o de sessão, o de requisição e o de página. Eles são detalhados a seguir.
O escopo de aplicação, ou applicationScope, é global e mais abrangente em comparação aos demais, no qual atributos são compartilhados no contexto da aplicação toda, sendo acessível pelo elemento ServletContext.
Esse escopo é iniciado com a primeira requisição da aplicação e permaneceativo na memória do servidor até a aplicação ser removida do contêiner web. Tecnicamente falando, para criar e atribuir um valor a uma variável no escopo de aplicação utilizamos o seguinte código:
this.getServletContext().setAttribute("nome", "valor");
Para recuperação desse valor, utilizamos o código:
this.getServletContext().getAttribute("nome");
Um bom uso do escopo de aplicação é compartilhar configurações globais da aplicação, como por exemplo, usuário e senha de um banco de dados. Atributos desse escopo podem também ser criados no arquivo no web.xml.
Por sua vez, o escopo de sessão, ou sessionScope, é vinculado ao acesso de um determinado usuário, permanecendo ativo até que o usuário deixe o sistema, por inatividade ou saída explícita, que é o momento em que ele invoca algum elemento de saída, que destrói a sessão.
O tempo de inatividade, que acaba por encerrar uma sessão, é uma proteção sistêmica que pode ser configurado de acordo com a necessidade da aplicação. Essa característica é conhecida comumente pelos usuários como expiração do tempo de sessão.  
Para inserir atributos no escopo de sessão, utilizamos o código:
request.getSession().setAttribute("nome", valor);
Para recuperação desse valor, utilizamos o código:
request.getSession().getAttribute("nome");
Considerando que o protocolo HTTP não armazena estado, faz-se  necessário o uso de alguma técnica para identificar o usuário para o servidor e também para armazenar tais dados.
Uma das possibilidades para armazenar os dados de sessão seria realizar a persistência no lado do cliente e ir atualizando a cada requisição, porém essa solução não é usada por ser mais lenta e insegura. Como alternativa, apenas um identificador de sessão é transmitido ao servidor e isso normalmente é feito por meio da tecnologia de cookies.
No caso de o navegador do usuário não suportar ou não permitir o uso de cookies, a API, ainda assim, permite o uso de sessões pela inclusão de um identificador de sessão nas URLs.
Já o escopo de requisição, ou requestScope, envolve toda a criação e utilização de objetos no processo básico de requisição, que ocorre desde o início do pedido do cliente até a resposta ser devolvida pelo servidor via HTTP.
É importante ressaltar que, para responder a uma requisição, o contêiner web pode processar diferentes arquivos e, desse modo, os itens persistidos no escopo de requisição podem ser acessados em todos esses arquivos.
Para inserir atributos no escopo de requisição utilizamos o código:
request.setAttribute("nome", valor");
Para recuperação desse valor, utilizamos o código:
request.getAttribute("nome");
O último tipo de escopo a ser detalhado aqui é o escopo de página, ou pageScope, que só existe em JSPs. Ele é o de vida mais curta entre os tipos vistos, só existindo durante o processamento da página.
Cabe ressaltar que outra característica importante dos escopos é a visibilidade da informação. No escopo de sessão, cada usuário inicia uma sessão com o servidor e somente esse usuário tem acesso às variáveis dessa sessão. Desse modo, ficam várias sessões abertas no servidor, uma para cada usuário. Já o escopo de aplicação é compartilhado para todos os usuários.
Utilizando Expression Language (EL), não é preciso informar em qual escopo está sendo buscado o atributo, sendo esse código assim formado:
${nome}
Como o escopo não é informado, o web contêiner irá buscar o atributo seguindo a ordem do escopo mais restrito até o mais amplo, a saber: de página, de requisição, de sessão e de aplicação. 
Páginas JSP
A tecnologia Java Server Pages (JSP) é uma extensão dos servlets criada para facilitar o trabalho do desenvolvedor. Trabalhando com JSP, o desenvolvedor pode usar um gabarito HTML, criado por uma equipe de design, por exemplo, e acrescentar o código dinâmico, salvando o arquivo com a extensão .jsp (Kurniawan, 2002).
Vale destacar que JSP não é uma substituição dos servlets, mas sim um meio mais fácil e ágil de trabalhar com a tecnologia Java para web. Na prática, um arquivo JSP é convertido em servlet no contêiner web para o processamento necessário. O desenvolvedor também pode trabalhar com as duas tecnologias juntas.
Uma aplicação web utilizando a tecnologia JSP tem a seguinte estrutura de pastas, conforme visto na Figura 2.
Figura 2. Parte da estrutura de pastas de uma aplicação web que utiliza JSPs.
As pastas presentes no web contêiner podem ser assim descritas:
Clique nas abas para saber mais
WEBCONTENTWEB-INFMETA-INF
É a base da aplicação web, contendo arquivos HTML, documentos JSP, imagens e arquivos texto que serão entregues aos clientes para a formação da página HTML. É considerado o que compõe o front-end da aplicação web. Subpastas podem ser criadas pelo desenvolvedor para organizar melhor os arquivos (isso é definido na arquitetura da aplicação), como é o caso:
· Da pasta “imagens”, que separa as imagens (isso melhorará a legibilidade da arquitetura da aplicação, facilitando a manutenção);
· Da pasta “area-restrita”, que agrupa arquivos que precisam de autenticação de segurança;
· Da pasta “erros”, que contém as páginas personalizadas para apresentação de erros.
Para acrescentar código para programação e processamento dinâmico Java nos documentos HTML, são utilizados os chamados scriptlets.
DICA
Existe uma prática de desenvolvimento interessante que é a de programar comportamentos automáticos para favorecer a solução dos erros encontrados na aplicação. Isso é feito criando páginas personalizadas para erros que, além de apresentarem o erro ao usuário, gravam detalhes em bases de dados e ainda enviam e-mail avisando informações do problema aos desenvolvedores.
Scriptlets e suas variantes
Os scriptlets são blocos de código de uma página JSP que começam com uma marcação <% e terminam com a %>.
CURIOSIDADE
O nome scriptlet tem origem na língua inglesa, cujo início script significa "roteiro" ou código em linguagem script, e o sufixo let indica o diminutivo (algo pequeno), ou seja, um pequeno script.
Além dessas marcações simples, é possível acrescentar elementos nelas para ter acesso a novas funções, como:
· Comentários: <%-- coloque o comentário aqui --%> ou
<%
/* comentário com
mais de uma linha /*
 %>
· Declaração de atributos e métodos: <%! %>
· Saída (output) de resultados: <%= %>  
· Diretivas de inserção de elemento ou informação ao contêiner:
<%@ tipo page, include ou taglib %>
O uso dos scriptlets pode ser considerado um trunfo para a economia de código e consequente agilidade que os JSPs agregam no desenvolvimento Java para web. Na verdade, o uso de scriptlets é feito com sucesso em outras tecnologias como PHP (geralmente usando as marcações <? e ?>) e Microsoft ASP (que também utiliza as mesmas marcações do JSP).
DIRETIVAS
Diretivas são elementos de código dos scriptlets que fornecem informações ao contêiner sobre a página JSP, podendo incluir páginas ou bibliotecas de classes que serão utilizadas nessa página.
Existem três tipos de diretivas principais:
Clique nas abas para saber mais
INCLUDEPAGETAGLIB
Insere o conteúdo de um arquivo. É frequentemente utilizado para incluir trechos que são repetidos em todas as páginas de um site, como cabeçalho, menus e rodapé;
A diretiva page é fundamental para o funcionamento dos JSP na sua preparação com recursos de programação que serão informados ao servidor. Ela tem a sintaxe <%@ page %>, em que podem ser informados atributos de acordo com a necessidade, a saber:
Clique nos botões para saber mais
autoFlush=”true | false”
+
buffer=”none | 10kb”
+
contentType=”text/html”
+
errorPage=”pagina-de-erro.jsp”
+
extends=”pacote.classe”
+
import=”pacote.classe”
+
info=”texto-desejado”
+
isErrorPage=”true | false”
+
language=”java”
+
pageEncoding=”ISO-8859-1”
+
session=”true | false”
+
CURIOSIDADE
MIME type é um texto que informa o tipo existente em um conjunto de dados, sendo um padrão de classificação de tipos de arquivos na Internet. MIME significa Multi-purpose internet Mail Extensions, tendo esse nome por nascer da necessidade de rotular partes de códigos (como anexos)em e-mails, porém hoje em dia é também frequentemente usado por clientes web saberem o que fazer quando recebem um conjunto de dados. Um MIME type é dividido em duas partes: um tipo e um subtipo, separados por uma barra. Por exemplo, o MIME type para arquivos do Microsoft Word é “application/msword”.
Objetos implícitos
Além de colocar o código Java dentro de documentos HTML, os autores da tecnologia JSP tiveram outra ideia interessante para proporcionar maior produtividade no desenvolvimento das aplicações Java para web: o uso de objetos implícitos.
Os objetos implícitos são instâncias de classes disponibilizadas ao desenvolvedor. O seu funcionamento é simples: o compilador, ao ver que foi utilizado um objeto implícito dentro de uma página JSP, automaticamente os disponibilizará no servlet, de acordo com a API utilizada.  
Veja como o conceito de objetos implícitos facilitam a vida do desenvolvedor. Primeiro, temos a versão de um código sem o conceito.
1. PrintWriter out = response.getWriter();
2. out.print(“JSP é fácil”);
E agora veja o código-fonte usando o objeto implícito out, que realiza a saída de dados:
1. <% out.print(“JSP é fácil”); %>
Como o objeto out é um dos mais utilizados na programação, existe ainda outra facilidade para o desenvolvedor: o uso da marcação <%= resumindo ainda mais o código: 
1. <%= “JSP é fácil” %>
Compreendida a importância do uso desse conceito, iremos apresentar agora detalhes de cada objeto implícito disponível na tecnologia JSP.
// Request e response
Nos JSPs, temos instâncias das classes de requisição, a HttpServletRequest associada ao objeto request, e a de resposta, HttpServletResponse, associada ao objeto response.
O objeto request permite o acesso a todas as informações da requisição pelo usuário no lado do cliente (como parâmetros e cabeçalhos).
Vale ressaltar que os parâmetros recebidos, na maioria das vezes, vêm como resultado da submissão de formulários. Um exemplo de código de formulário simples pode ser visto a seguir.
1. <form action="verifica-usuario.jsp" method="post">
2. <p>Nome:<input type="text" name="nome" id="nome"></p>
3. <p>Telefone:<input type="text" name="fone" id="fone"></p>
4. <p><input type="submit" value="Submeter"></p>
5. </form>
E para receber os dados submetidos nesse formulário com o objeto implícito request, usamos o seguinte código.
1. <% String nome = request.getParameter(“nome”); %>
2. <% String fone = request.getParameter(“fone”); %>
Já o objeto response é utilizado para gerenciar respostas do servidor. Um código frequente de sua utilização está relacionado ao método sendRedirect, que redireciona o usuário para outra página.
1. <% response.sendRedirect(“http://localhost/outra-pagina.jsp”); %>
// Out
O objeto out representa um objeto javax.servjet.jsp.JspWriter, fazendo a transferência (ou saída) de textos gerados em Java para o documento HTML.
// Session
O objeto session representa o objeto da classe javax.servlet.http.HttpSession, permitindo a realização de todo o controle de sessões, como criação, destruição e, ainda, obtenção de valores de variáveis presentes em uma sessão.
Os métodos da classe HttpSession podem ser vistos no Quadro 1 a seguir:
Quadro 1. Métodos da classe HttpSession.
A partir do entendimento de seus métodos, apresentamos dois códigos-fontes que utilizam o objeto implícito session. No próximo código-fonte, tem-se a criação de uma sessão a partir da verificação se o usuário digitou corretamente suas credenciais (nome e senha).
1. if (request.getParameter("email").equals("teste@teste.com.br") && request.getParameter("password").equals("123")) {  
2. session.setAttribute("email", request.getParameter("email"));
3. session.setAttribute("password",
    request.getParameter("password"));
4. }
5. response.sendRedirect("area-restrita/");
Já neste código, temos a verificação se a sessão existe para conceder acesso à página.
1. String emailUser = session.getAttribute("emailUser");
2. if (emailUser != null){
3. //Sessão aberta
4. //ação para usuário logado
5. } else {
6. session.invalidate();
7. response.sendRedirect("login.jsp");
8. }
Em nosso caso, esse trecho que verifica sessão de usuário foi colocado dentro de um filtro, para que a avaliação seja feita em todos os arquivos de páginas que estiverem dentro da pasta “area-restrita”.
// Application
O objeto application realiza referência à interface javax.servlet.ServletContext permitindo o acesso aos dados do contexto da aplicação. Assim, é possível armazenar informações que podem ser vistas em todo o contexto de aplicação.
O método utilizado com mais frequência para obter os valores de atributos definidos no arquivo web.xml é o getInitParameter. Sua utilização pode ser vista no código:
<%= application.getInitParameter("bd-user") %>
// Config
O objeto config faz referência ao objeto da interface jaxax.servlet.ServletConfig, contendo os dados de configuração de uma página específica, armazenados no Deployment Descriptor.
Sua utilização é útil quando se deseja definir um atributo que vale apenas para um determinado servlet, ou seja, não sendo uma informação de importância global para a aplicação.
Um exemplo de sua utilização é em uma página que cadastra autores de uma publicação, em que foi criado um atributo no web.xml que vale somente para esse servlet:
<%= config.getInitParameter("numero-maximo-autores") %>
Para declarar atributos que valem apenas para um servlet:
1. ...
2. <servlet>
 3. <servlet-name>adicionaPublicacao</servlet-name>  
4. <int-param>
5. <param-name>numero-maximo-autores</param-name>
6. <param-value>8</param-value>
7. </init-param>
8. </servlet>
9. ...
// PageContext
O objeto implícito pageContext representa a interface javax.servlet.jsp.PageContext, que é bem poderosa, permitindo o acesso a todos os escopos existentes no JSP e a outros objetos relativos a um determinado servlet. Alguns de seus métodos são:
· getRequest: retorna um ServletRequest;
· getResponse: retorna um ServletResponse;
· getServletConfig: retorna um ServletConfig;
· getServletContext: retorna um ServletContext;
· getSession: retorna o HttpSession;
· getOut: retorna o JspWriter.
// Page
O objeto page representa a interface javax.servlet.jsp.HttpJspPage, funcionando para obtenção de acesso às informações da própria página JSP. Esse objeto equivale ao uso do comando “this” no servlet.
// Exception 
O objeto exception é uma instância do objeto java.lang.Throwable, representando uma exceção, que corresponde a algum erro ocorrido nos processamentos de páginas no servidor.
Um tipo de exceção que pode ocorrer frequentemente é a divisão de algum número por zero e esse objeto implícito armazenará todos os dados da exceção. O método geralmente utilizado para obter a causa da exceção no formato de string textual é o getCause().
Lembre-se que quando ocorrer algum erro de servidor, serão retornadas as páginas listadas nos elementos com a marcação <error-page> no arquivo web.xml. O exemplo a seguir mostra um trecho de código de uma página de erro (error-500.jsp)
1. ...
2. <%@ page isErrorPage="true" %>
3. ...
4. <body>
5. <h1>Exceção encontrada!</h1>  
6. A exceção é: <%= exception.getCause() %>
7. </body> 
8. ...
Na Figura 3, é apresentada a tela da página gerada a partir de uma exceção de divisão por zero, colocada de propósito em uma outra página.
Figura 3. Página gerada a partir do código que usa o objeto implícito exception.
Conforme visto na Figura 3, a personalização de páginas de erro é um item de desenvolvimento que agrega maior usabilidade à aplicação, demonstrando preocupação dos desenvolvedores em mostrar de uma maneira melhor o que ocorreu, informando que será corrigido.
Funcionamento interno do JSP
Para apresentar de modo didático detalhes de funcionamento interno da tecnologia JSP, iremos apresentar passos, figuras e exemplos de códigos com as devidas explanações.  
O ponto de partida para esse desenvolvimento é a montagem do ambiente, que já foi detalhada neste material e que envolve resumidamente a instalação do JDK para execução dos códigos Java, do Apache Tomcatcomo contêiner web e do Eclipse como ambiente de desenvolvimento integrado (IDE).
Com o ambiente preparado, o desenvolvedor deve criar um projeto no Eclipse do tipo “Dynamic Web Project”, conforme pode ser visto na Figura 4.
Figura 4. Criando o projeto de uma aplicação Java para web no Eclipse.
Não se esqueça de alterar o “Target runtime” para a versão do Tomcat instalada, do mesmo modo em que foi feito na Figura 4. Com essa configuração realizada, tem-se a integração entre o Tomcat e o Eclipse, permitindo o uso do tradicional botão “Run”, que executa o código para teste do desenvolvedor.
Com o projeto criado, você deve criar suas páginas HTML, de conteúdo estático, páginas JSP e servlets, que fazem o processamento e a geração das páginas dinâmicas. Ao selecionar no Eclipse a opção de novo arquivo do JSP, abrem-se as telas de guia para auxílio ao desenvolvedor, conforme podem ser vistas nas Figuras 5 e 6, apresentadas a seguir.
Figura 5. Assistente do eclipse para criação de um JSP.
Na Figura 5, é possível ver que a IDE já orienta para que os arquivos JSP sejam gravados na pasta padrão “<nomedoprojeto>/WebContent/”, bastando o desenvolvedor escolher o nome de seu arquivo. Reforçamos aqui a orientação de escolha de bons nomes (claros e significativos) para os arquivos JSP, facilitando futuras manutenções e o acesso do usuário.
O próximo passo na criação de arquivo JSP é a apresentação de um facilitador que o Eclipse disponibiliza ao desenvolvedor, em que a própria IDE oferece templates (gabaritos) de códigos prontos. Esse passo é opcional e pode ser visto na Figura 6.
Figura 6. Escolha do template (gabarito) desejado do JSP a ser criado.
Como pode ser visto na Figura 6, o Eclipse dispõe de variados templates de código, desde o HTML 4.01, passando pelo mais novo (5.0), até diferentes versões usando XHTML.
Existe ainda um recurso que permite incluir novos templates, sendo útil para padronizar e otimizar a geração de códigos iniciais de uma equipe de desenvolvimento (lembre-se que, na prática, um site ou aplicação web pode conter centenas ou, ainda, milhares de páginas JSP).
Após a abertura do editor de JSPs do Eclipse com esse novo arquivo criado, o desenvolvedor deve digitar o código-fonte de acordo com os requisitos desejados para a aplicação. Observe o código a seguir.
1. <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
2. pageEncoding="ISO-8859-1"
3. import="java.util.Date"
4. import="java.text.SimpleDateFormat"%>
5. <!DOCTYPE html>
6. <html>
7. <head>
8. <meta charset="ISO-8859-1">
9. <title>Meu primeiro JSP</title>
10. </head>
11. <body>
12. <h1>Olá Mundo!</h1>
13. <% 
14. SimpleDateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
15. Date dataAtual = new Date();
16.String textoDataAtual =dateFormat.format(dataAtual);
17. %>
18. <p>Data do servidor: <%= textoDataAtual %></p>
19. </body>
20. </html>
É de visível percepção, a partir do código apresentado, que a codificação está mais legível e menor nesse JSP se compararmos a um Servlet que fizesse a mesma função. Como pode ser visto no código-fonte na linha 1, temos a diretiva page informando ao servidor a linguagem a ser utilizada nos scriptlets, o Java, o tipo do conteúdo e seu código de conjunto de caracteres charset e as importações de pacotes necessários, que nesse caso são relacionados à utilização e à formatação de data do servidor.
Nas linhas de 7 a 10, temos o cabeçalho do documento HTML com a declaração do código de conjunto de caracteres charset, que coincide propositalmente com a declaração da linha 1 e o título da página, que aparece, geralmente, na aba no navegador.
Nas linhas 11 e 12, temos o início do corpo do documento HTML com uma marcação de título de seção H1, também chamados de heading tags. Já nas linhas de 13 a 17, temos a porção de processamento para geração dinâmica da página, em que é definido o formato da data. Na linha 14, é obtida a data do servidor; na linha 15, é finalmente formatada essa data e na linha 16, o resultado é gravado na variável do tipo string chamada textoDataAtual.
Vale lembrar que essa parte de código de processamento Java para geração de páginas dinâmicas, cujos comandos geraram a data atual do servidor, por exemplo, é igual à programação Java nos moldes clássicos (não web). Ou seja, toda documentação de classes Java deve ser utilizada pelo desenvolvedor para escrever seu código (é inviável e fora do escopo deste material descrever aqui todas as classes do Java, a ideia aqui é de mostrar o caminho que o desenvolvedor deve percorrer).
A visualização no navegador da página processada pode ser vista na Figura 7, apresentada a seguir.
Figura 7. Página resultante do processamento do código exemplo.
Note que a página resultante no navegador é bem simples, não apresentando estilos CSS nem tampouco processamento complexo no servidor. Ela apenas representa o primeiro passo para o desenvolvedor que, nesse momento, já possui o ambiente de trabalho pronto, com editor de páginas, classes e um contêiner para processamento das páginas.
Ou seja, ele está apto a evoluir seus desenvolvimentos, agregando, por exemplo, estilos nas páginas e mais funções de processamento, como gravação e recuperação de dados em Sistemas Gerenciadores de Bancos de Dados (SGBDs).
Outro ponto que merece explicação é o da escolha do nome de arquivo para essa primeira página, o “index.jsp”. Lembre-se que esse nome foi o escolhido no atributo <welcome-file> do arquivo “web.xml” e ele é, ainda, o nome mais utilizado pela comunidade de desenvolvimento. O fato de ele estar listado como página de boas-vindas nessa configuração faz com que o usuário possa acessá-la simplesmente pelo endereço da URL, que deve se assemelhar a: http://localhost/exemplo1.
UPLOAD DE ARQUIVOS
O upload de arquivos é um importante recurso dos sistemas web que permite que formulários do navegador possam transmitir arquivos de modo confiável para o servidor.
Para criar um campo de envio de arquivos em formulários, é necessário utilizar um formulário do tipo “multipart/form-data” que usa o método POST e a marcação <input name=”nome-do-campo” type=”file”> e o trabalho posterior está na página de processamento da requisição no lado do servidor, armazenando o arquivo na pasta desejada pelo desenvolvedor. Um exemplo de formulário com envio de um arquivo por upload pode ser visto no código-fonte a seguir.
1. <!DOCTYPE html>
2. <html>
3. <head>
4. <meta charset="ISO-8859-1">
5. <title>Upload de arquivo</title>
6. </head>
7. <body>
8. <h1>Upload de arquivo</h1>
9. <form action="UploadAction.jsp" method="post"
enctype="multipart/form-data">
10. <p>Arquivo: <input type="file" name="arquivo"></p>
11. <p>Descrição: <input type="text" name="descricao"></p>
12. <p><input type="submit" value="Envia"></p>
13. </form>
14. </body>
15. </html>
Note que o formulário irá enviar pelo método POST os dados de seus campos, incluindo os bytes do arquivo desejado, para a página JSP indicada no atributo “action” da linha 9, que é a “UploadAction.jsp”. Caso o desenvolvedor deseje, esse action também poderá indicar um Servlet.
Para realizar a gravação de um arquivo recebido em uma página, o desenvolvedor tem duas opções: fazer manualmente um filtro que lê a requisição ou usar bibliotecas prontas. Neste material iremos utilizar duas bibliotecas prontas do projeto Apache Commons, visto que são gratuitas, já testadas e de fácil utilização. São elas: a commons-fileupload-1.4[1] e a commons-io-2.6[2].
Para utilizar bibliotecas que agregam recursos ao seu projeto, basta fazer o download no formato de arquivo .jar e copiá-las para a pasta “WEB-INF\lib”. O conteúdo do arquivo “UploadAction.jsp” pode ser visto então no código-fonte que é apresentado a seguir.
1. <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
2. pageEncoding="ISO-8859-1"%>
3. <%@ page import="java.io.*,java.util.*, javax.servlet.*" %>
4. <%@ page import="org.apache.commons.fileupload.*" %>
5. <%@ page import="org.apache.commons.fileupload.disk.*" %>
6. <%@ page import="org.apache.commons.fileupload.servlet.*"%>
7. <%@ page import="org.apache.commons.io.output.*" %>
8. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
9. <html>
10. <head>
11. <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
12.<title>Gravando arquivo</title>
13. </head>
14. <body>
15. <%
16. File file;
17. int maxFileSize = 5000 * 1024;
18. String caminho = "C:/workspace/exemplo1/WebContent/uploads/";
19. if ((request.getContentType().indexOf("multipart/form-data") >= 0)) {
20. DiskFileItemFactory factory = new DiskFileItemFactory();
21. ServletFileUpload upload = new ServletFileUpload(factory);
22. upload.setSizeMax( maxFileSize );
23. try{ 
24. List fileItems = upload.parseRequest(request);
25. Iterator i = fileItems.iterator();
26. while ( i.hasNext () ) {
27. FileItem fi = (FileItem)i.next();
28. if ( !fi.isFormField () )  {
29. String fileName = fi.getName();
30. file = new File(caminho + fi.getName());
31. fi.write( file );
32. out.println("Arquivo enviado: " + caminho + fileName);
33. }
34. }
35. } catch(Exception ex) { System.out.println(ex); }
36. }
37. %>
38. </body>
39. </html>
Agora é a hora de sintetizar tudo o que aprendemos nessa unidade. Vamos lá?!
SINTETIZANDO
Esta unidade se iniciou com a apresentação do Deployment Descriptor, incluindo suas possíveis configurações feitas no arquivo web.xml, um exemplo comentado de configuração e como ferramentas de software podem ajudar na escrita desse arquivo. Com o entendimento do Deployment Descriptor, o desenvolvedor tem condições plenas de realizar uma arquitetura organizada da aplicação, mapeando servlets nas URLs e filtros para restringir acessos a áreas restritas, por exemplo.
Em seguida, foi abordado o conceito acerca dos diferentes escopos de aplicações Java para web, que são os seguintes: aplicação, sessão e requisição.
De modo técnico, foi apresentado, ainda, o mecanismo de funcionamento de scriptlets e suas variantes, para formar as páginas JSP, fornecendo a base para que o aluno possa criar aplicações dinâmicas para o crescente mercado atual. A unidade foi, então, encerrada com conteúdo mais avançado que envolveu o uso de biblioteca específica para melhorar e adicionar recursos ao contêiner web, que é o caso do upload de arquivos.