Desenvolvimento web com Java e tecnologias relacionadas Struts :: Webwork :: JSF :: AJAX :: Spring :: JasperReport/JFreechart Eclipse :: NetBeans & Tecnologias relacionadas
Rafael Rocha Cavalcanti
SCJP 1.5 :: SCWCD 1.4 :: LPI(away) Colaborador do GUJ e Debian-PE Arquiteto/Engenheiro :: Stefanini Recife-PE
[email protected] :: http://faelcavalcanti.wordpress.com
Missão :: Objetivo Apresentar, motivar e exercitar o desenvolvimento para plataforma Java EE para Web, utilizando Servlet’s e JSP, bem como adequação do framework Struts entre tecnologias relacionadas como AJAX além de uma breve introdução sobre conceitos da Web2.0
2
Metodologias utilizadas neste curso • • • •
Exposições e discussões teóricas Exercícios práticos de projeto Modelagem voltado à realidade em projetos Fórum :: Lista de Discussão Meio de unificar o grupo interessado sobre o assunto • Manter perspectivas de inovações e soluções a todos • Retirar dúvidas quando não presente •
3
O que este curso não cobre ou não é ? •
Não cobre • Desenvolvimento para outras plataformas que não seja Java • Desenvolvimento para outras plataformas do Java como •
•
•
Java SE, Java ME e até Java EE Avançado
Técnicas de persistência em banco de dados
Não visa • Aprendizado de lógica de programação • Desenvolver programas para terceiros
4
Cronograma do Curso Curso Parte 1
Parte 2
Parte 3
Parte 4
Introdução
Web Applications
Framework Struts
AJAX e Web 2.0
Camadas de Rede e Protocolos
Servlet’s
Struts 1.1
Evolução Arquitetura
JSP
Struts 2.0
Java EE
Tag Libraries
JSTL 5
Livros sugeridos
6
Antes de iniciarmos ... • • • •
• • •
Nome Empresa que trabalha Onde estuda ou estudou Experiência da área de Engenharia de Software • Desenvolvimento de software com Java na plataforma Web • Desenvolvimento em outras plataformas Experiência em outras áreas Razões para estar fazendo este treinamento Quais são as suas expectativas deste curso
7
Introdução
Camadas da rede, Protocolos e Linguagens
Uma perspectiva de sua evolução
8
Intro I :: Uma abordagem sobre a evolução
9
Intro I :: Camada de pilhas de protocolo
depois
antes
10
Intro I :: Comunicação entre camadas
11
Intro I :: Modelo OSI (Open Systems Interconnect)
12
Intro I :: Modelo TCP/IP (Visão Interna)
13
Intro I :: Comparativo entre os modelos TCP/IP x OSI •
Modelo TCP/IP • • • •
•
Pilha de protocolos da internet na camada de apresentação Utiliza conceito de [port] para gerenciar processos num [host] Mais útil para entendimento das redes atuais Não possui as camadas de sessão e apresentação
Modelo OSI •
Camada física sujeita a erros •
• •
Lida com aspectos mecânicos, sinais elétricos e outros meios físicos
Não é rico suficientemente nas camadas mais baixas Transferência de dados fim entre processos e hosts
14
Intro I :: Topologia TCP/IP (Arpanet)
15
Intro I :: Plataformas disponíveis “W3C”
16
Intro I :: Topologia (Abordagem entre Camadas) •
Proporcionalidades • • •
Disponibilidade de várias linguagens interpretadas e compiladas Novas tendências proporcionada de acordo com a necessidade Novos modelos de arquiteturas simbolizam novos adeptos (paadigmas)
17
Intro I :: HTTP (HyperText Transfer Protocol) •
•
Surgiu com a necessidade de informações em 1990; •
Utiliza a porta 80 como padrão (implícita na url)
•
Comunica-se com o servidor através de HTML (Hypertext Markup Language)
Primeira versão chamada HTTP/0.9 •
•
A versão HTTP/1.0 foi desenvolvida entre 1992 e 1996 •
Suprir necessidade de transferir não apenas texto Passou a transferir novos tipos MIME (Multipurpose Internet Mail Extension)
•
Foram implementados novos métodos como [POST] e [HEAD]
•
•
Protocolo através de texto ASCII e possuía único método [GET]
Versão atual HTTP/1.1 descrito em 1999 na RFC2606 • • •
Uso de conexões persistentes e servidores com suporte a proxy; Foram adicionados novos métodos Também adotado como protocolo genérico para os outros [FTP]
18
Intro I :: Linguagem HTML (HyperText Markup Language) •
Especificação formal desenvolvida por Tim Berners-Lee • •
Tecnologia fruto do casamento dos padrões Hytime e SGML Desde de 1996, as especificações vêm sendo mantidas pela W3C Consequentemente tornou-se também uma norma internacional • Última especificação lançada com a recomendação HTML 4.01 •
•
Linguagem de marcação de texto •
Objetivo de manter apresentação dos dados •
• •
Renderização do conteúdo ocorre na interpretação pelo browser Um arquivo HTML pode ter extensão .htm ou html •
•
Não possui informação sobre os dados apresentados(diferente XML)
Este arquivo é composto por diversas tags (formatação dos dados)
Diversas extensões comumente utilizadas :: DHTML e XHTML
19
Intro I :: HTML (Exemplo de código)
20
Evolução do modelo Arquiteturas
Uma breve abordagem
21
Intro II :: Evolução quanto à arquitetura •
Atuações de aplicações enterprise • • • •
•
Benefícios quanto a evolução das aplicações enterprises • •
•
Presentation Logic :: Lógica de apresentação Business Logic :: Lógica de negócios Data access logic :: Lógica de acesso aos dados System services :: Serviços de sistemas
Definição de tipo de flexibilidade em fazer mudanças Deslocamento da localização dos serviços de sistemas
Evolução por camadas • • •
Single tier Two tier Three tier • •
•
RPC based Remote object based
Three tier (HTML browser e Web server)
22
Intro II :: Arquitetura Single Tier (Orientada via Mainframe) • • • •
Terminais burros são conectados diretamente para o mainframe Modelo centralizado (oposto ao modelo distribuído) Todas as camadas presentes dentro de uma aplicação no mainframe Prós : • •
•
Gerenciamento no cliente não é requerido Consistência dos dados é facilmente arquivada
Contra : • •
Funcionalidade centralizada (todas as camadas em uma só) Dificuldades para atualizações e manutenções, inclusive pouco reuso
23
Intro II :: Arquitetura Two Tier (Modelo Cliente-Servidor) Clientes sobrecarregados conversando com servidor de dados • Execução da lógica de negócios e apresentação processada no cliente • Prós : •
•
•
Independência fabricante de banco de dados
Contras : Dificuldade de atualizações e manutenções • Alto acoplamento no modelo de dados •
• •
•
Alto tráfico de rede •
•
Atualizações tornam-se custosas Cada cliente é comprometido Transferência feita por poucos dados
est u q re se n SQL o re s p L SQ
T CP /I P TC P/ IP
Dependência de configuração de banco •
Instalação de cliente de base de dados 24
Intro II :: Arquitetura Three Tier (Baseado no modelo MVC) Cliente magro :: Negócios e dados separados da apresentação • Lógica de negócios e acesso dos dados ficam residem no servidor • Prós : •
•
•
Mais flexibilidade de mudanças na lógica de negócios
Contras : • •
Complexidade é introduzida na camada de midle-tier server Cliente e midle-tier possuem alto acoplamento Implementação depende da infra-estrutura relacionada • Pouca eficiência no reuso de código •
RPC request
SQL request
RPC response
SQL response database
25
Intro II :: Arquitetura Three Tier (Modelo de Objetos) •
Lógica de negócios e dados são capturados como objetos Agora são descritos dentro de uma abstração (contrato de interface) • Modelo de objetos utilizados em linguagens :: CORBA e Java/RMI •
Prós : • Acoplamento um pouco mais baixo do que o modelo RPC • Código pode mais reusável • Contras : • Complexidade na camada de midle-tier server ainda necessita ser endereçada •
Object request
SQL request
Object response
SQL response database
26
Intro II :: Arquitetura Three Tier (Modelo Web-server) •
Facilitação pelos browsers Lógica de apresentação e conversação com servidor via HTTP • Lógica negócios e dados são manipulados como conteúdo dinâmico •
•
•
Entre outras tecnologias :: CGI, Servlet, ASP, PHP, Python, Perl, Ruby, ...
Prós : Sem gerenciamento no cliente, necessita apenas do browser • Suporte para vários tipos de dispositivos como celulares, palms, etc. •
•
Contras : •
Alta complexidade na camada de midle-tier server
HTML request
SQL request
HTML response
SQL response database
27
Intro II :: Comparativo (Camadas x Modelo de arquitetura) •
Single-tier •
•
Única camada de desenvolvimento. Código difícil de ser mantido
Multi-tier Separação em diversas camadas. • Manutenções mais flexíveis sem afetar as outras camadas •
•
Monolítico •
•
1(um) binário por arquivo, compilado(código-objeto), link-editado, redistribuído o tempo todo a cada modificação de sistema
Baseado em objetos Partes plugáveis, reuso, melhor design(coeso), fáceis atualizações, etc. • Possibilita que fase de projeto não dependa da fase de desenvolvimento •
28
Intro II :: Observações e questionamentos •
Complexidade na camada intermediária ainda persiste? •
Duplicidade de serviços de sistemas ainda necessitam ser providas para uma maior extensibilidade de aplicações (enterprise applications) Controle de concorrência e transações • Load-balancing e segurança • Gerenciamento de recursos e Pool de Conexões •
•
Como resolver este problema • •
Comumente compartilha-se o container que manipula os serviços de sistemas que estão em uma camada superior Código proprietário versus código aberto (independência de fabricante)
29
Intro II :: Abordagem de soluções (Proprietárias x Fechadas) •
Soluções proprietárias •
Modelo de “containers e componentes” •
• •
Lógica de negócios entrelaçada com classes de componentes.
O contrato entre componentes e containers são definidos dentro de uma de arquitetura fechada. Problem of proprietary solution: Vendor lock-in Exemplo: Tuxedo, .NET • Não se pode reimplementar ou redefinir. Depende do fornecedor. • Atualmente extensões open-source, estão se beneficiando dos frameworks existentes de diversas plataformas como java. •
•
Soluções abertas •
•
Modelo de “containers e componentes” no qual o container provê serviço de sistemas dentro de uma arquitetura aberta mantida por grandes parceiros mundiais e individuais. (IBM, Red Hat, ...) :: JCP J2EE/JEE fundamentalmente provê portabilidade de código pela plataforma Java e consequentemente seus componentes(frameworks) 30
Porquê Java EE?
Uma introdução básica na arquitetura Java EE
31
Java EE :: Ganho de plataforma pelos desenvolvedores •
Pode ser usado em qualquer implementação de modelo J2EE/JEE • •
•
Vasta quantidade de recursos disponíveis por diversas comunidades •
•
Produção de qualidade mantida por implementações genéricas na qual é livre e disponível a re-implementação e redistribuição (copyleft) Também possui outros produtos para fins comerciais visando manter um controle alternativo escalável e tolerante a falhas. Inúmeras referências, monografias, livros, padrões, frameworks;
Podem implementar em junção com componentes de terceiros •
Visando manter compatibilidade com tecnologias de outros fabricantes ou hardwares específicos
32
Java EE :: Ganho de plataforma pelos fornecedores Fornecedores trabalham em conjunto colaborando com a evolução da especificação da plataforma Java • Competem dentro das implementações específicas •
•
•
Em áreas de escalabilidade, performance, avaliabilidade, gerenciamento, e desenv olvimento de ferramentas customizáveis
Liberdade para inovar enquanto mantém a portabilidade da aplicação, ao invés de focar em melhores ou novas re-implementações já existentes e de grande aceitação e qualidade
33
Java EE :: Ganho de plataforma pelos usuários Aplicação portável (portabilidade garantida pela plataforma Java) • Muitas implementações escolhem as possibilidades disponíveis baseadas em vários requerimentos •
• • •
Preço (free para grandes softwares/sistemas) Escalabilidade, desde um único CPU para processados com clusters(EJB) Ferramentas de performace
Inúmeros desenvolvedores no mundo todo • A maioria das distribuições Linux, hoje, já o acompanham (GPLv2)
•
34
Java EE :: Arquitetura (Visão Geral)
35
Java EE :: Arquitetura (Uma outra visão)
36
Java EE :: API disponível e tecnologias relacionadas •
J2EE 1.4 APIs and Technologies • • • • • • • • • • •
J2SE 1.4 (improved) JAX-RPC (new) Web Service for J2EE J2EE Management e Deployment JMX 1.1 JMS 1.1 JTA 1.0 Servlet 2.4 JSP 2.0 EJB 2.1 JavaMail 1.3
•
Java EE 5 • • • • • • •
JAX-WS 2.0 & JSR 181 Java Persistence (JPA) EJB 3.0 JAXB 2.0 JavaSever Faces 1.2 new JSP 2.1 Others
37
Java EE :: Novas API’s incorporadas no Java EE 5
38
Web Applications Colocar subtítulo
39
WebApplications :: Introdução Evolução do modelo de arquitetura cliente-servidor • Diferentemente de sites web, gerenciam conteúdo dinâmico •
• • •
Conteúdo no qual será processado por um servidor de aplicação web Servidor retorna conteúdo HTML que será renderizado pelo browser Os elementos de uma aplicação web ficam residentes no servidor
Popularizados como clientes magros (Facilitam distribuição) • Possuem muitas variações de estrutura de acordo com a plataforma •
•
Geralmente sua estrutura é implementado em 3(três) camadas
Podem ser escritos em qualquer linguagem (tratamento depende do servidor) • Exemplo de linguagens suportadas • Java, Python, Ruby, PHP, Perl, ASP, CGI, ColdFusion, ....
•
40
WebApplications :: Objetos Request e Response •
Request •
Informações que são enviadas para o servidor pelo cliente Por onde o usuário envia os dados a partir de um formulário HTML • No qual os cabeçalhos da requisição são enviados via HTTP •
•
Reponse •
Informações que são enviados para o cliente a partir do servidor Conteúdos :: Text(html/plain) ou binários(imagem) :: [Content Type] • HTTP headers, cookies, etc •
41
WebApplications :: Ciclo de vida • • • • • •
1 :: Cliente solicita requisição via web browser (HTTP) 2 :: Container web recebe requisição e envia para um controlador (Servlet) 3 :: (Opcional) Servlet encaminha requisição via JNDI para um outro servidor (EJB) 4 :: Servlet delega requisição para a camada de negócio (Model) 5 :: Servlet obtem informações enviadas e prepara para retornar os dados para cliente 6 :: Web browser obtem informações processadas via HTTP e consequentemente são interpretadas via JSP/JSF e renderizadas na tela para o cliente via DHTML
42
WebApplications :: Estrutura de diretórios em Java
43
Entendendo o modelo MVC (Visão caixa preta) • • • • •
Um dos primeiros padrões identificados. Surgiu com a comunidade de Smaltalk. Objetivo principal era desacoplar implementações entre camadas (Código mais coeso) Model :: Comumente representado por “Beans” e serviços da aplicação (Negócio) View :: Representado por um JSP/JSF. Também pode ser escrito por um Servlet. Controller :: Geralmente implementado a partir de um Servlet, Actions(Struts), etc.
44
Outra visão do modelo MVC (caixa branca)
45
Outra visão do Modelo MVC (detalhada)
46
Servlet’s
Visão Geral, API e Ciclo de Vida
47
Servlet’s :: Introdução Objetos Java no qual estendem a funcionalidade de um servidor web • São independentes de plataforma e servidor de aplicações web •
•
Melhor alternativa do que CGI(Common Gateway Interface), ISAPI, NSAPI •
•
•
Para cada nova requisição um novo processo é criado (Até se for no mesmo cliente)
Gerenciamento de sessão e são independentes de plataforma (Mais eficiente)
Diferenças entre o modelo baseado Servlet’s e CGI
48
Servlet’s :: Onde estão localizados na arquitetura JEE ? •
Servlet’s estão inseridos dentro do servidor de aplicações web • •
Efetua o gerenciamento de requisições do usuário Podem ser escalonáveis com outras arquiteturas e com outros servidores
49
Servlet’s :: Principais características •
São programas em Java •
•
Performace • • •
•
Multiplataforma e tem praticamente toda a plataforma Java disponível Máquina virtual está no lado do servidor e não no cliente (browser) São carregados na memória apenas na primeira vez (servidor:container) Podem executar pedidos concorrentemente
Sumário funcional geral • • • •
Recebem requisições do cliente (via HTML por requisição HTTP request) Extraem informações do ambiente (contexto) para o container Efetua geração de conteúdo ou processa/delega lógica de negócios Envia resposta para o cliente (via HTML por requisição HTTP response) ou envia requisição para outro Servlet ou JSP para que possa renderizar o conteúdo processado
50
Servlet’s :: Hierarquia estrutural de classes
51
Ciclo de vida de um Servlet Gerenciamento definido e controlado pelo container • Principais métodos •
•
init() •
•
service() • •
•
Chamado uma única vez quando o servlet é carregado Chamado para cada requisição (Recebe objetos de pedido e resposta ) Pode ser usado simultanealmente por vários Threads.
destroy() •
Chamado uma única vez quando o servlet é carregado
52
Servlet’s :: Como implementar um Servlet (primeiros passos) Estender a classe [ java.servlet.http.HttpServlet ] • Redefinir os métodos doGet e/ou doPost •
Estes são os métodos básicos necessários para tratar requisições • Existem outros métodos extensíveis suportados pela especificação W3C •
•
•
doOptions, doDelete, doTrace, doHead,
Dentro dos métodos doGet/doPost Ler os parâmetros vindos do formulários HTML ou da URL • Processar os parâmetros, fazer validações, instanciar classes auxiliares e básicas, assim como chamar métodos de negócio • Gerar resposta final para o cliente •
53
Servlet’s :: Tratamento de exceções •
Exceções relevantes para tratamento de exceções em Servlets •
javax.servlet.ServletException •
•
Falha geral no Servlet
javax.servlet.UnavaiableException Permanente :: Esperando ação do administrador do servidor de aplicação • Temporário :: Problemas como disco cheio, falhas no servidor •
•
java.io.IOException •
•
Exceção genérica que caracteriza problemas no fluxo dos dados via I/O
Geralmente esta funcionalidade pode ser tratada de diversas formas •
Declarar exceção e diretiva <error-page> no DD (web.xml) •
•
Também pode ser declarado uma diretiva dentro do próprio JSP
Utilizar outros frameworks que estendem esta funcionalidade
54
Servlet’s :: Escopo de Objetos (Estado entre requisições) •
Necessidade •
•
Problema •
•
Possibilita guardar algum tipo de informação durante requisições O protocolo HTTP não mantém estado (stateless)
Alternativas Campos hidden(ocultos) entre formulários em HTML • Utilização de cookies no cliente • Reescrita de URL’s • Utilização de sessões (javax.servlet.http.HttpSession) •
55
Servlet’s :: Escopo de Objetos (Acessibilidade) •
Application (Web Context) :: javax.servlet.ServletContext • •
Obtém informações de ambiente Compartilhado por toda a aplicação •
•
Só existe uma instância na aplicação
Também utilizado para Registrar logs necessários • Redirecionar para uma página •
•
Session :: javax.servlet.HttpSession •
Acessado durante várias requisições •
•
•
Utilizar somente o necessário!
Request :: javax.servlet.HttpRequest • •
•
Exemplo do carrinho de compras
Acessado durante uma única requisição Extensivamente utilizado
Page :: javax.servlet.jsp.PageContext • •
Acessível a partir de uma página JSP Visível somente dentro de um arquivo JSP.
56
Servlet’s :: Cookies •
Necessidade •
•
Manter informações no cliente durante múltipla sessões no browser
Problema •
Vulnerabilidade no lado do cliente • •
•
Alternativas •
Utilizar a técnica do URL Rewriting • •
•
Um hacker poderia obter informações pessoais do usuário Geralmente configura-se o browser para desabilitar o uso de cookies
URL +”;jsessionid=1234567” Métodos :: encodeURL() ou encodeRedirectURL(“/TestPage.do”)
Informações •
Pode ser definido um timeout no cliente caso esteja habilitado •
Pode ser setado a partir do método setMaxAge()
57
Servlet’s :: Listeners •
Necessidade •
•
Problema •
•
Obter informações da aplicação durante determinados eventos Baixa performance, problemas internos, expiração de sessão, outros.
Alternativas • •
Depende de que tipo de informações é necessário resguardar para identificação Extensibilidade do padrão Observer
58
Servlet’s :: Listeners (Diferença entre diversos cenários) Atributos de listeners
ServletRequestAttributeListener ServletContextAttributeListener HttpSessionAttributeListener
Outros ciclo de vida de listeners (não possui “Attribute” na classe)
ServletRequestListener ServletContextListener HttpSessionListener HttpSessionBindingListener HttpSessionActivationListener
Métodos de atributos de listeners (exceto binding listeners)
attributeAdded() attributeRemoved() attributeReplaced()
Ciclo de eventos (Sessão) (exceto eventos de atributos)
Quando o objeto Session é criada e quando é destruída sessionCreated() sessionDestroyed()
Ciclo de eventos (Request) (exceto eventos de atributos)
Quando o Request é inicializado ou destruído requestInitialized() RequestDestroyed()
Ciclo de eventos (Contexto) (exceto eventos de atributos)
Quando o Contexto da aplicação é inicializado ou destruído contextInitialized() contextDestroyed()
59
Servlet’s :: Características e configuração Provê notificações de mudanças de estado dentro da aplicação • Cada aplicação web possui suas particularidades •
• •
Desde o contexto da aplicação, bem como de um objeto na sessão Mudanças nestes estados podem ser notificados através do uso de listeners
Podem ser utilizados para gerenciamento • Conexões de banco de dados quando a aplicação é publicada ou cai • Contadores específicos para alguma funcionalidade • Monitorar conexões HTTP e atributos de sessão ou outro escopo • Devem estar configurados dentro do DD(web.xml)
•
<listener> <listener> <listener-class>myApp.myContextListenerClass <listener-class>myApp.myContextListenerClass
60
Servlet’s :: Listeners (Implementando) •
Exemplo de implementação de um Listener •
Neste caso quando o contexto da aplicação é inicializado ele aciona o evento •
•
O método contextInitialized é chamado()
Quando o contexto é destruído(undeployed), contextDestroyed() é executado
import import javax.servlet.*; javax.servlet.*; import import javax.servlet.http.*; javax.servlet.http.*; public public class class AppListener AppListener extends extends HttpServlet HttpServlet implements implements ServletContextListener ServletContextListener {{ private private ServletContext ServletContext context context == null; null; public public void void contextInitialized(ServletContextEvent contextInitialized(ServletContextEvent event) event) {{ context context == event.getServletContext(); event.getServletContext(); context.setAttribute(“counter", context.setAttribute(“counter", “parametro.localizacao.ambiente” “parametro.localizacao.ambiente” ); ); }} public public void void contextDestroyed(ServletContextEvent contextDestroyed(ServletContextEvent event) event) {{ context context == event.getServletContext(); event.getServletContext(); context.log context.log ((String)context.getAttribute(“counter")); ((String)context.getAttribute(“counter")); context.removeAttribute("counter"); context.removeAttribute("counter"); }} }}
61
Java Server Pages (JSP)
Visão Geral, Ciclo de vida, Expressões
62
JSP :: Introdução •
Documentos baseados em textos capazes de retornar conteúdos ambos estáticos e dinâmicos para o cliente através de um browser •
Conteúdo estático •
•
Conteúdo dinâmico •
•
HTML, XML e textos entre as tags do formulário Código java, disponibilização de dados através de TAG’s customizáveis
Diferencas entre Servlets e JSP Servlets incluem código de apresentação (HTML) no código Java • JSP inclui um conjunto entrelaçado de código DHTML e/ou java •
•
•
Constitui de uma página DHTML com conteúdo dinâmico(java ou TAG’s)
Vantagens Introduz novos comandos que facilitam o desenvolvimento de páginas • Facilita manutenção para o designer, o sistema é composto de páginas •
•
Desvantagens •
Falta uniformidade na programação. Pode afetar legibilidade e coesão. 63
JSP :: JSP2.0 (O que cobre a nova especificação?) •
O que cobre a nova especificação JSP 2.0 • • • • •
EL (Expression Language) Simple TAG extension TAG files Provê suporte para arquivos XML Outros recursos a partir da JSR 152 (JSP 2.0)
64
JSP :: Exemplo (Implementado dentro do NetBeans)
65
JSP :: Ciclo de Vida • •
1 :: Ao receber uma requisição, o container lê o DD(web.xml) para esta aplicação 2 :: O container tenta traduzir o arquivo JSP associado a esta requisição Como o JSP é lido em tempo de execução ele necessita do JAVA_HOME setado • Consequentemente será criado um arquivo “.java”, tendo um Servlet implementado • Caso exista um erro no JSP a exceção javax.servlet.jsp.JspException será lançada •
• • •
3 :: O container tenta compilar o novo servlet gerando um arquivo “.class” 4 :: O container carrega o arquivo “.class” pela máquina virtual java 5 :: O container instância o servlet e delega a execução do método jspInit() •
JSP é processado uma única vez, e este acabará sendo 1º passo na próxima requisição • •
•
Considerando isto para um mesmo arquivo JSP Caso o arquivo seja modificado, uma nova requisição efetuará todos os passos anteriores
6 :: O container cria uma novaThread para manipular a requisição do cliente Após a execução do método jspInit(), é então executado o método _jspService() • Eventualmente o servlet envia uma resposta(response) de volta para o cliente •
•
Observações O desenvolvedor não precisa conhecer o servlet gerado • Qualquer alteração necessária, será feita dentro do próprio JSP e não no Servlet gerado •
66
JSP :: Ciclo de Vida (Visão Geral)
67
JSP :: Ciclo de Vida (Fluxo de requisições) • •
Para uma nova requisição é verificado se existe uma instância no container Caso não tenha sido carregado o container associa uma nova thread ao servlet
68
JSP :: Objetos implícitos • • • • •
Páginas JSP possuem alguns objetos implícitos, estando sempre disponíveis, sem necessidade de declaração, como usado na diretiva [page:import] São criados e gerenciados pelo container da aplicação Correspondem aos mesmo objetos implícitos dos Servlets Alguns objetos sob determinadas condições :: (session e exception) Relação de objetos implícitos • request :: javax.servlet.http.HttpRequest • response :: javax.servlet.http.HttpResponse • out :: javax.servlet.http.JspWriter extends java.io.Writer • session :: javax.servlet.http.HttpSession • exception :: java.lang.Throwable • application :: javax.servlet.ServletContext • pageContext :: javax.servlet.jsp.PageContext • config :: javax.servlet.ServletConfig 69
JSP :: Elementos existentes (Parte 1) •
Directive •
•
Fornecem Instruções ao container sobre como a página deverá funcionar e quais recursos ela necessita para que seja completamente carregada
Declaration •
Utilizado para definições de novos métodos e variáveis que consequentemente são inseridos dentro do corpo da classe do servlet gerado na compilação do JSP •
•
•
Serão elementos da própria classe. Ficarão fora do corpo do método _jspService().
Usualmente são utilizados em conjunto com Expressions e/ou Scriptlets
Scriptlet •
Utilizados para visualizar arbitrariamente pequenas informações •
Geralmente a inserção deste trecho de código ficará residido dentro do método _jspService() após compilado o arquivo JSP.
70
JSP :: Elementos existentes (Parte 2) •
Expression •
•
São pequenas expressões de código Java que consequentemente serão atribuídas e repassadas a partir de uma String dentro do corpo da página de um JSP
EL Expression •
Recurso importante introduzido a partir da JSTL (veremos mais adiante) •
•
•
Propriedades poderão ser acessadas desde que esteja dentro do padrão JavaBean
JSP Standard Action • • •
•
Forma simples de acessar objetos declarados em qualquer escopo da aplicação
TAG’s customizadas a fim de facilitar o desenvolvimento de aplicações web Permitem a inserção de menos código Java dentro de um JSP São executadas em tempo de requisição
Observações •
Qualquer objeto implícito pode ser acessado por qualquer elemente descrito •
•
Veremos objetos implícitos mais adiante
O projetista pode desabilitar o uso de scripting no DD(web.xml) 71
JSP :: Diretivas Instruções genéricas e independente de requisições (Meta-construções) • Comumente empregados na fase de tradução e compilação • Sintaxe •
•
•
<%@ directive {opcao=valor} %>
Existem três tipo de diretivas •
Page :: <%@ page {opcao=valor} %> Controla a estrutura do Servlet através da importação de classes • Estabelece informações quanto ao tipo de conteúdo que será utilizado dentro do JSP •
•
Include :: <%@ include {opcao=valor} %> Instrui o container a inserir o conteúdo do recurso identificado pela diretiva • O recurso é incluído na página JSP antes da transformação/renderização total • Geralmente utilizado por menus e barras de informações específicas •
•
Taglib :: <%@ taglib {opcao=valor} %> Indica ao JSP qual identificador poderá ser utilizado mediante alguma TAG • Geralmente utilizado como “ALIAS” de uma TAG em específico que foi construída •
72
JSP :: Diretiva :: Page (Parte 1) É recomendável declarar no ínicio dos arquivos JSP • Podem ser declarado várias vezes, mas cada opção só aparecerá uma vez •
•
•
Exceto a opção import que poderá aparecer várias vezes
Opções disponíveis para a diretiva page •
autoflush :: <%@ page autoflush=“true” %> •
•
buffer :: <%@ page buffer=“32kb” %> •
•
Identifica cabeçalho de resposta, indicando o tipo MIME enviado
isErrorPage :: <%@ page isErrorPage=“false” %> •
•
Define o tamanho de buffer utilizado no JspWriter para o cliente em Kb
contentType :: <%@ page contentType=“text/html” %> •
•
Controla se o buffer de saída será flushed quando estiver cheio
Define se a página corrente pode atuar como página de erro
errorPage :: <%@ page errorPage=“url_pagina_erro” %> :: URL relativo •
Define qual página será invocada caso alguma exceção ocorra
73
JSP :: Diretiva :: Page (Parte 2) •
Continuando resumo de opções disponíveis para a diretiva page •
extends :: <%@ page extends=“packageA.packageB.Class” %> •
•
Info :: <%@ page info=“Mensagem qualquer” %> •
•
Utilizado para especificar a linguagem de programação base no JSP
import :: <%@ page import=“java.util.Locale” %> •
•
Define se o servlet irá implementar a interface SingleThreadModel
language :: <%@ page language=“smaltalk” %> •
•
Define se a página utilizará algum recurso de sessão HTTP ou não
isThreadSafe :: <%@ page isThreadSafe=“true” %> •
•
Define uma string que será recuperada do servlet através do método
session :: <%@ page session=“true” %> •
•
Indica a superclasse do servlet que será gerada a partir da página JSP
Também utilizado em mesma conformidade para declarar imports
Observações •
Os exemplos de declarações das diretivas pages encontram-se em sua forma padrão ou comumente utilizados em sua normalidade funcional 74
JSP :: Diretiva :: Include •
O conteúdo é inserido antes da renderização da página. Exemplo de uso :: •
------
Curso Java Web Rafa