Título do Curso

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>
<listener-class>myApp.myContextListenerClass</listener-class>
</listener>
</listener>
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 ::
•
------
<html>
<head>
<title>Curso Java Web Rafa</title>
</head>
<body>
<form action=“loginPage.do” method=“GET” id=“form” >
<%@ include file=“menu.html” %>
</form>
</body>
</head>
</html>
•
------
<html>
<head>
<body>
Hello World!!!
</body>
</head>
</html>
•
------
75
JSP :: Diretiva :: Taglib
Define a TAG disponibilizada para o JSP corrente que irá interpretar
• Segue abaixo um pequeno exemplo de uso ::
• -----•
<%@ taglib prefix=“myCustomTAGs” uri=“rafa” %>
<html>
<head>
<title>Exemplo de uso de custom tags</title>
</head>
<body>
<form action=“loginPage.do” method=“GET” id=“form” >
<rafa:tabelaDinamica />
</form>
</body>
</head>
</html>
•
•
------
Posteriormente será abordado exemplos de uso de TAG’s customizáveis
76
JSP :: Declarações
Dentro de uma declaração também pode ser sobrescrito(override) métodos
como jspInit() e jspDestroy(), modificando o estado de execução do JSP
• Código análogo ao action :: <jsp:declaration> METODO </jsp:declaration>
• -----•
<html>
<body>
<h1>Using jspInit and jspDestroy</h1>
<%! int number;
public void jspInit() {
number = 5;
}
public void jspDestroy() {
number = 0;
}
%>
<%
out.println("The number is " + number + "<BR>");
%>
</body>
</html>
•
------
77
JSP :: Scriplets
•
Podem realizar operações que os [ Expressions ] não são capazes como:
•
•
•
•
•
Nehuma destes itens acima é considerado uma boa prática
•
•
Setar informações para o header do formulário, assim como código do status
Escrever um log para o servidor
Atualizar uma base de dados
Executar códigos mais sofisticados como laços condicionais
Ao invés disto é recomendável o uso de JSTL, Actions e TAG’s customizáveis
-----<html>
<body>
<h1>Using Scriplets</h1>
<body>
<%
int number;
out.println("The number is " + number + "<br>");
%>
</body>
</html>
•
-----78
JSP :: Expression
•
Geralmente são utilizados para visualizar informações breves como
•
Data atual
<%= new java.util.Date() %>
•
Número randônico
<%= java.lang.Math.random() %>
•
Informações do usuário logado
<%= ((myApp.model.User)request.getAttribute(“user”)).getName() %>
•
Recomendado utilizar EL Expression, Custom TAG’s e JSTL
79
JSP :: EL Expression
•
Disponibilizado em 2003 a partir da evolução do JSP 2.0 com JSTL
•
•
Objetivo era trazer alternativa ao uso de scripting dentro de páginas JSP
Primeiramente introduzido na versão JSTL 1.0
EL Expression facilita a integração do estado do servidor
• Podem ser usado dentro de declaração de TAG’s customizáveis
• Exemplo de expressão com EL Expression
•
${applicationScope.mail}
${person.dog.name}
•
Expressão equivalente com Java Expression
<%= application.getAttribute(“mail”) %>
<%= ((foo.Person) request.getAttribute(“person”)).getDog().getName() %>
80
JSP :: EL Expression (Relação de Objetos implícitos)
•
Possibilidades de objetos implícitos dentro do escopo de EL
Todos são objetos implícitos :: Map
•
•
•
•
•
•
•
•
•
•
•
pageScope
requestScope
sessionScope
applicationScope
param
paramValues
header
headerValues
cookie
initParam
pageContext
Caso não seja explicitado o valor ele irá buscar dentro dos
4 escopos, uma referência com o name especificado.
Foi o caso do exemplo utilizando person!
1.
1.
2.
2.
3.
3.
Java
Java Language
Language Naming
Naming Rules
Rules
Pode
Pode iniciar
iniciar com
com letra,
letra, underline
underline ee dolar
dolar “$”
“$”
Números
Números poderão
poderão aparecer
aparecer após
após letras
letras
Palavras
Palavras reservadas
reservadas não
não são
são permitidas
permitidas
------------------Qualquer
Qualquer violação
violação destas
destas regras
regras uma
uma
exceção
exceção será
será levantada!
levantada!
De todos os objetos implícitos citados acima, somente
pageContext não é do tipo Map. Ele é uma atual referência
do objeto pageContext, e pageContext é um javaBean!
81
JSP :: JSP Standard Action
São compostas de TAG’s padrões usadas para realizar operações que
normalmente só eram possíveis através do uso de scripting
• Com versão do JSP 2.0 temos disponível as seguintes actions
•
•
•
•
•
•
<jsp:useBean ... />
• Tenta recuperar um bean declarado em um determinado escopo
<jsp:setProperty ... />
• Atribui valores a uma propriedade de um determinado bean especificado
<jsp:getProperty ... />
• Efetua a invocação para um método de acesso de um bean
• Consequentemente faz conversão implícita para um tipo String de retorno
<jsp:include ... />
• Análogo à diretava <%@ include file=“menu.html”/>
• A vantagem é que este action trata conteúdo em tempo de execução
<jsp: forward ... />
• Também redireciona a chamada para outro JSP, além de poder escrever nele
82
JSP :: Complexidade x Robustez
•
Necessidade de estender componentes para reuso
•
Equipe necessita se beneficiar de TAG’s padrões customizáveis afim de suprir as
funcionalidade bem como atender a demanda solicitada
83
Custom Tag’s
Custom TAG Library Description (TLD)
84
Custom Tags :: Introdução
Assim como os JSP Standard Action, podemos definir nossas TAG’s
• Principais objetivos/benefícios
•
Reusar componentes dentro do JSP
• Diminuir quantidade de código Java nas páginas
• Deixar o arquivo JSP mais legível, facilitando para o designer
•
•
Alguns exemplos de TAG’s que poderiam ser customizadas
•
•
•
•
•
Montagem de uma tabela dinâmica a partir de uma coleção no request
Manipulação de arquivos
Páginação de buscas
Combo genérico, como uma listagem de Cidades por Estado
Diversos outros a partir de componentes DHTML, ActiveX, Flash, etc.
85
Custom Tags :: Introdução
•
Existem diversas TAG’s disponíveis, inclusive com recursos AJAX
•
•
•
•
•
•
Struts Framework e TAG’s do Struts-Layout
TagLib Apache Jakarta Project
TAG’s disponíveis pelo JSTL
JSF :: Java Server Faces (inúmeros baseados JSF: Richfaces, Icefaces, etc.)
Diversas outras poderão ser encontradas facilmente na internet
Existem dois tipos de implementação de Custom TAG’s
Simple TAG handler
• Classic TAG handler
•
86
Custom Tags :: Forma estrutural e Comunicação
•
Entendendo a estrutura de diretórios e a comunicação entre os artefatos
87
Custom Tags :: API (Sumário)
•
Classic TAG extensions (JSP 1.2 e 2.0)
Controle e manipulação de TAG’s complexas
• Escrito somente dentro da linguagem java e criado por desenvolvedores de bibliotecas TAG
•
•
SimpleTag extension e TAG files (Disponível apenas no JSP 2.0)
TAG’s mais facilitadas, possibilitando a extensibilidade por meio de sintaxe JSP
• Pode ser criado por autores de página JSP ou desenvolvedores de bibliotecas de TAG’s
•
88
Custom Tags :: API (Visão extendida)
•
Diagrama de classes :: API
•
Foi necessário a criação da interface JspTag para relacionar as duas formas
•
Neste aspecto ela foi projetada apenas para fins organizacionais entre os dois tipos
89
Custom Tags :: Classic Tag (Especificação JSP 1.2)
•
Existem duas possibilidades para implementação de TAG’s Classic
•
TagSupport
•
Define uma TAG sem corpo (configurado por padrão)
•
•
•
Dentro da implementação do método doAfterBody(), é possível acessar o corpo da TAG
Apenas uma iteração será efetuada dentro do corpo
BodyTagSupport
Define uma TAG com corpo. Possibilidade de efetuar iterações dentro do corpo
• Métodos constantemente utilizados
•
•
•
•
setBodyContent()
• Chamado pelo JSP quando setado para processar corpo da TAG
• Seta propriedades de conteúdo para carregamento do corpo pelo formulário
doInitBody()
• Executado logo após método setBodyContent(). Não é chamado para TAG’s vazias.
• Onde efetua o processamento do corpo.
Métodos equivalentes para duas formas.
doStartTag() :: Carregado durante inicialização da TAG
• doAfterBody() :: Processado após o carregamento do corpo da TAG
• doEndTag() :: Chamado durante finalização da TAG
•
90
Custom Tags :: Classic Tag :: TagSupport (Ciclo de Vida)
91
Custom Tags :: Classic Tag :: Tag Support (Implementando)
•
Passos necessários
1 :: Escrever uma classe que estenda javax.servlet.jsp.tagext.TagSupport
• 2 :: Implementar os métodos que tratarão o comportamento da TAG
•
•
Podem ser implementados os métodos (não são obrigatórios)
doStartTag()
• doAfterBody()
• doEndTag()
•
3 :: Criar um arquivo TLD para a TAG
• 4 :: Declarar o arquivo TLD dentro do DD (web.xml)
• 5 :: Escrever o arquivo JSP que utiliza esta TAG
•
92
Custom Tags :: Classic Tag :: Tag Support (Artefatos)
Arquivo TLD
<taglib
<taglib ....>
....>
<tag>
<tag>
<name>curso</name>
<name>curso</name>
<tag-class>teste.Curso</tag-class>
<tag-class>teste.Curso</tag-class>
<body-content>empty</body-content>
<body-content>empty</body-content>
</tag>
</tag>
</taglib>
</taglib>
Referência do TLD no DD(web.xml)
<web-app
<web-app ...>
...>
<jsp-config>
<jsp-config>
<taglib>
<taglib>
<taglib-uri>curso</taglib-uri>
<taglib-uri>curso</taglib-uri>
<taglib-location>
<taglib-location>
/WEB-INF/tld/sample.tld
/WEB-INF/tld/sample.tld
</taglib-location>
</taglib-location>
</taglib>
</taglib>
</jsp-config>
</jsp-config>
<web-app>
<web-app>
Classe estendida de TagSupport
public
public class
class Curso
Curso extends
extends TagSupport
TagSupport {{
private
private PageContext
PageContext pageContext;
pageContext;
public
public int
int doStartTag()
doStartTag() throws
throws JspException
JspException {{
try
{
try {
pageContext.getOut().print(“Hello”);
pageContext.getOut().print(“Hello”);
}} catch
catch (IOException
(IOException e)
e) {{
throw
new
JspException(“erro");
throw new JspException(“erro");
}} return
return SKIP_BODY;
SKIP_BODY;
}}
public
public int
int doEndTag()
doEndTag() throws
throws JspException
JspException {{
return
return EVAL_PAGE;
EVAL_PAGE;
}}
}}
Arquivo JSP
<%@taglib
<%@taglib prefix="rafa“
prefix="rafa“ uri="curso"%>
uri="curso"%>
<html>
<html>
<head>
<head>
<title>TagSupport</title>
<title>TagSupport</title>
</head>
</head>
<body>
<body>
<br/>
<br/>
<center>
<center>
<rafa:curso/>
<rafa:curso/>
</center>
</center>
</body>
</body>
</html>
</html>
93
Custom Tags :: Classic Tag :: BodyTagSupport (Ciclo de Vida)
94
Custom Tags :: Classic Tag :: BodyTagSupport (Ciclo de Vida)
•
Passos necessários
1 :: Escrever uma classe que estenda javax.servlet.jsp.tagext.BodyTagSupport
• 2 :: Implementar os métodos que tratarão o comportamento da TAG
•
•
Podem ser implementados os métodos (não são obrigatórios)
•
•
•
•
•
doStartTag()
doInitBody()
setBodyContent( BodyContent )
doAfterBody()
doEndTag()
3 :: Criar um arquivo TLD para a TAG
• 4 :: Declarar o arquivo TLD dentro do DD (web.xml)
• 5 :: Escrever o arquivo JSP que utiliza esta TAG
•
95
Custom Tags :: SimpleTag (Especificação JSP2.0 - Implementando)
•
Passos para implementação
•
•
•
•
•
1 :: Escrever uma classe que estenda [ javax.servlet.jsp.tagext.SimpleTagSupport ]
2 :: Implementar o método doTag()
3 :: Criar um arquivo TLD para a TAG
4 :: Declarar o arquivo TLD dentro do DD (web.xml)
5 :: Escrever o arquivo JSP que utiliza esta TAG
96
JSTL
Java Server Pages Standard TAG Library
97
JSTL :: Introdução
Conjunto de bilbiotecas pré-definidas pela SUN Microsystems
• Engloba biblioteca diversas funcionalidades comuns para diversos JSP
•
•
•
•
•
•
Iterações e condicionais
Processamento XML
Acesso a base de dados
Formatação e Internacionalização
Outras vantagens
•
•
•
•
Você não tem que escrever suas próprias Tag’s
Apenas deverá entender e utilizar todas as Tag’s disponíveis providas pela J2EE
Código se torna mais conciso com a presença de Tag’s JSP
Portabilidade garantida
98
JSTL :: Tags libraries disponíveis
•
Seguem abaixo tipos de implementações de TAG’s JSTL disponíveis
•
Core
•
Define Tag’s para os processamentos mais comuns como
•
•
Database
•
•
•
Garante formatação de números, datas, entre outros campos customizáveis
XML e XPath
•
•
•
Acesso e manipulação de dados dentro de um JSP
Cuidado com a arquitetura em camadas. Este não é o papel do JSP.
Formatting
•
•
Condições, Loop’s, switch, redirecionamentos, impressões e outros
Biblioteca para manipulação e navegação de estrutura de arquivos XML
Também é possível efetuar parser entre outras transformações
I18N (Internacionalização)
•
Centraliza através de páginas JSP um ponto comum para
99
JSTL :: Core Tag Library
•
Exemplos
•
Código implementado utilizando scriptlet
<%
<%
java.util.Iterator
java.util.Iterator ii == cartelas.iterator();
cartelas.iterator();
Cartela
cartela
=
null;
Cartela cartela = null;
while(
while( i.hasNext()
i.hasNext() )) {{
cartela
cartela == (Cartela)
(Cartela) i.hasNext();
i.hasNext();
%>
%>
<%
<%
•
<%=
<%= cartela.numero
cartela.numero %>
%>
}} %>
%>
Código utilizando TAG’s JSTL
<c:out>
<c:out>
<c:set>
<c:set>
<c:remove>
<c:remove>
<c:if>
<c:if>
<c:choose>
<c:choose>
<c:when>
<c:when>
<c:otherwise>
<c:otherwise>
<c:forEach>
<c:forEach>
<c:import>
<c:import>
<c:url>
<c:url>
<c:redirect>
<c:redirect>
<c:forEach
<c:forEach items=“${cartela}”
items=“${cartela}” var=“bingo”>
var=“bingo”>
<c:out
<c:out value=“${bingo.numero}”/>
value=“${bingo.numero}”/>
</c:forEach>
</c:forEach>
•
Exemplo de declaração de referência para a TAg dentro do JSP
<%@
<%@ taglib
taglib prefix=“c”
prefix=“c” uri=“http://java.sun.com/jstl/core”
uri=“http://java.sun.com/jstl/core” %>
%>
100
JSTL :: Database Tag Library
•
Disponíveis nas situações para
Consultas
• Atualizações
• Transações
•
•
<sql:setDataSource>
<sql:setDataSource>
<sql:query>
<sql:query>
<sql:update>
<sql:update>
<sql:param>
<sql:param>
<sql:dataParam>
<sql:dataParam>
<sql:transaction
<sql:transaction
Observações
O objetvo é demonstrar as funcionalidades
• Porém não é considerado uma boa prática
• Exemplo de declaração de referência para a TAG
•
<%@
<%@ taglib
taglib prefix=“sql”
prefix=“sql” uri=“http://java.sun.com/jstl/sql”
uri=“http://java.sun.com/jstl/sql” %>
%>
101
Struts framework
Apache Software Foundation
102
Struts :: Visão Geral
Framework open-source criado e mantido pela Jakarta Project
• Mantém estruturação de uma aplicação web
•
•
•
Disponibiliza desenvolvimento através da separação do modelo MVC
Utilizado para construção de páginas utilizando Servlet’s e JSP
•
•
Também inclui um conjunto de Custom TAG’s com a biblioteca
Orientado a padrões
Singleton, Composite View, Front Controller, Business Delegate
• Filter Intercepting, Command, inclusive o pattern MVC
•
•
•
Possui diversos recursos como validação, internacionalização, etc.
Facilita mapeamento de requisições através de arquivos em XML
103
Struts :: Arquitetura (Overview)
104
Struts :: Arquitetura (Particularidades)
•
Struts é focado no controle de requisições na camada de visão
•
Fluxo de requisição é mediado pelo controlador chamado Action
•
•
•
•
Após excutado a regra, o Action controla esta delega a um JSP
•
•
•
Os Actions também podem ser usados na camada de modelo
A camada de modelo encapsula a lógica de negócios e estado
Por este motivo não é recomendado este tipo de lógica nos Actions
Este mapeamento é feito a partir de um arquivo de configuração
Maior benefício disto é o baixo acoplamento entre a visão e modelo
Informações de acesso, mapeamento e fluxo de processo contém:
•
•
Actions(controladores) mapeam a requisição HTTP via XML
Possibilita estabelecer a navegação entre diversos Actions
105
Struts :: Arquitetura (Fluxos x Artefatos)
106
Struts :: Classe Action Servlet (Controlador)
•
Faz parte do Struts e estende a funcionalidade da classe HttpServlet
•
•
•
Foi projetado para interceptar requisições a fim de mediar o responsável
Toda requisição passa pelo ActionServlet e redireciona para o Action
Lê arquivo de configuração para determinar o fluxo de controle
Mapeamento do ActionServlet é feito dentro do DD(web.xml)
• Exemplo de mapemento. Toda requisição “*.do” é interceptada
•
<servlet>
<servlet>
<servlet-name>action</servlet-name>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<init-param>
<param-name>config</param-name>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config.xml</param-value>
<param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
</init-param>
<load-on-startup>1</load-on-startup>
<load-on-startup>1</load-on-startup>
</servlet>
</servlet>
<servlet-mapping>
<servlet-mapping>
<servlet-name>action</servlet-name>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
</servlet-mapping>
107
Struts :: Classe Action Servlet (Diagrama de Sequência)
•
Fluxo de controle dentro de um ActionServlet
108
Struts :: Classe RequestProcessor (Gerenciador Interno)
Provida pelo framework a fim de processar configurações estabelecidas
• Contém o fluxo lógico de processamento do ActionServlet
• Algumas implementações estabelecidas por esta classe
•
•
processPath :: Determina a pasta que foi invocada a requisição
•
processLocale :: Seleciona um Locale específico para esta requisição
•
processContent :: Seta o content type padrão para todas as requisições
•
processMapping :: Determina quais os mapeamentos necessários a este
•
processActionForm :: Instância e o coloca dentro de um escopo
•
processPopulate :: Popula um ActionForm associado ao formulário
•
processValidate :: Efetua pré-validação conforme ActionForm associado
•
processForward :: Efetua o mapemento entre Actions e JSP de saídas
•
processActionPerform :: Determina se o método que será chamado
109
Struts :: Classe Action (Controlador da aplicação)
ActionServlet recebe requisição e envia para o Action associado
• Struts associa o controle de requisições através do struts-config.xml
• Para que o desenvolvedor implemente um Action, deve-se:
•
•
•
Estender a classe :: org.apache.struts.action.Action
Sobrescrever(override) o método execute( .... )
Dentro deste método pode ser implementado toda a regra necessária
• Geralmente não é recomendável. Isto é responsabilidade da camada Model
• Consequentemente o envio(forward) para o JSP que resultará os dados
• Também poderá enviar para outro Action responsável
•
•
Efetuar o mapeamento da requisição no arquivo struts-config.xml
•
Geralmente este arquivo está localizado abaixo da pasta WEB-INF
110
Struts :: Classe Action (Exemplo de Implementação)
A implementação de um Action é comparado a um servlet
• Exemplo de implementação de um Action
•
package
package submit;
submit;
import
import
import
import
javax.servlet.http.*;
javax.servlet.http.*;
org.apache.struts.action.*;
org.apache.struts.action.*;
public
public class
class SubmitAction
SubmitAction extends
extends Action
Action {{
public
public ActionForward
ActionForward execute(ActionMapping
execute(ActionMapping mapping,
mapping, ActionForm
ActionForm form,
form,
HttpServletRequest
request,
HttpServletResponse
response)
HttpServletRequest request, HttpServletResponse response) {{
SubmitForm
SubmitForm ff == (SubmitForm)
(SubmitForm) form;
form; //
// obtem
obtem oo form
form bean
bean
//
// obtendo
obtendo oo ultimo
ultimo nome
nome ee
//
// setando
setando para
para oo escopo
escopo de
de request
request
String
lastName
=
f.getLastName();
String lastName = f.getLastName();
request.setAttribute("lastName",
request.setAttribute("lastName", lastName.toUpperCase());
lastName.toUpperCase());
//
// enviando
enviando controle
controle para
para um
um JSP
JSP específico
específico
return
return (mapping.findForward("success"));
(mapping.findForward("success"));
}}
}}
111
Struts :: Configuração : struts-config.xml
•
A implementação de um Action requer um mapeamento
11 <struts-config>
<struts-config>
22 <!-<!-- ==========
========== Definições
Definições de
de Action’s
Action’s Mapping
Mapping ============
============ -->
-->
33
<action-mappings>
<action-mappings>
44
55
<action
<action path="/submit"
path="/submit"
66
type="submit.SubmitAction"
type="submit.SubmitAction"
77
name="submitForm"
name="submitForm"
88
input="/submit.jsp"
input="/submit.jsp"
99
scope="request"
scope="request"
10
validate="true">
10
validate="true">
11
<forward
11
<forward name="success"
name="success" path="/submitSuccess.jsp"/>
path="/submitSuccess.jsp"/>
12
<forward
12
<forward name="failure"
name="failure" path="/submitFailure.jsp"/>
path="/submitFailure.jsp"/>
13
</action>
13
</action>
14
14
15
</action-mappings>
15
</action-mappings>
16
16
17
17 </struts-config>
</struts-config>
•
Para chamar um action com este mapeamento deverá utilizar a URL
•
[ http://host-server:porta\path ] :: http://127.0.0.1:8080/submit.do
112
Struts :: Classe ActionForm
ActionForm’s são classes estensíveis utilizadas por desenvolvedores
• Objetivo de acessar os parâmetros informados pela requisição
•
•
•
Intermedia para o Action informações do formulário
Eles podem atuar nos escopos de “Request” e “Session”
Também devem ser configurados no struts-config.xml
•
•
•
Primeiro deve-se declarar com uma tag <form-bean>
Posteriormente atribui a propriedade name da tag de Action.
public
public class
class LoginPageForm
LoginPageForm extends
extends ActionForm
ActionForm {{
private
private String
String user;
user;
private
private String
String password;
password;
public
public
public
public
String
String getName()
getName() {{ return
return
void
setName(String
void setName(String name)
name)
this.Name
this.Name }}
{{ this.name
this.name == name
name }}
public
public String
String getPassword()
getPassword() {{ return
return this.Name
this.Name }}
public
public void
void setPassword(String
setPassword(String password)
password) {{ this.password
this.password == password
password }}
}}
113
Struts :: Classe ActionForm (Uma visão de multi-formulários)
114
Struts :: DynaActionForm (Uma alternativa)
•
DynaActionForm foram criados a partir de ActionsForm’s
•
Incorporados a versão 1.1 do Struts
A diferenciação é justamente por manter esta configuração no XML
• O objetivo é o mesmo do ActionForm’s mantendo no struts-config
•
•
Devem estar declarados todos os parâmetros que esta requisição recebe
115
Struts :: Classe DispatchAction (Introdução)
Bastante utilizado para resolver várias requisições em única classe
• Diminui quantidade de código e Actions existentes na aplicação
•
•
•
•
Geralmente utilizado em um CRUD (Create, Read, Update e Delete)
Uma grande quantidade de métodos existentes indica alto acomplamento
Configurações de uso
•
Na chamada de uma Action é necessário especificar o request parameter
Pode ser especificado diretamente ou via javaScript no formulário HTML
• No struts-config, cada action, receberá o valor carregado em “parameter”
•
•
•
O valor será o nome do método a ser carregado a requisição
Não é mais necessário implementar o método execute()
116
Struts :: Classe Action (Exemplo de implementação)
Exemplo de implementação da classe DispatchAction
•
public
public class
class CRUDItemCompraAction
CRUDItemCompraAction extends
extends DispatchAction
DispatchAction {{
public
public ActionForward
ActionForward addItem(ActionMapping
addItem(ActionMapping mapping,
mapping,
ActionForm
ActionForm form,
form,
HttpServletRequest
HttpServletRequest request,
request,
HttpServletResponse
HttpServletResponse response)
response) throws
throws Exception
Exception {{
try
try {{
//
// implementacao
implementacao de
de codigo
codigo para
para insercao
insercao
}} catch(Exception
catch(Exception ex)
ex) {{ //exception
//exception }}
}}
public
public ActionForward
ActionForward deleteItem(ActionMapping
deleteItem(ActionMapping mapping,
mapping,
ActionForm
ActionForm form,
form,
HttpServletRequest
HttpServletRequest request,
request,
HttpServletResponse
HttpServletResponse response)
response) throws
throws Exception
Exception {{
try
try {{
//
// implementacao
implementacao de
de codigo
codigo para
para delecao
delecao
}} catch(Exception
catch(Exception ex){
ex){ //exception
//exception }}
}}
}}
117
Struts :: Tag Library (Principais Tags disponíveis a partir da API do Struts)
API do Struts povêm um conjunto bibliotecas de TAG’s para uso
• O uso destas TAG’s não é obrigatório mas foi bastante encorajado
• Principais tag-libs do Struts
•
•
struts-html
•
•
struts-logic
•
•
Tag responsável para acessar beans bem como suas propriedades
struts-template
•
•
Disponibiliza tags lógicas dentro do JSP a fim de eliminar scriptlets
struts-bean
•
•
Suporte para renderização entre camada de visão e componentes DHTML
Template para formulários em JSP, incluindo parametrização de conteúdo
struts-nested
Possibilidade para acessar hierarquia de objetos
• Facilita para renderização de listas a partir de outras listas
•
118
Struts :: Tag Library (Configuração a partir do DD)
Para utilizar um Tag library, é necessário mapear o seu arquivo TLD
• Todas as tag libraries são definidas dentro do web.xml usando <taglib>
•
<!-<!-- Struts
Struts Tag
Tag Library
Library Descriptors
Descriptors -->
-->
<taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
</taglib>
<taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>
<taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-html.tld</taglib-location>
<taglib-location>/WEB-INF/struts-html.tld</taglib-location>
</taglib>
</taglib>
119
Struts :: Tag Library (Exemplo de uso em um JSP)
•
Para utilizar um Tag library, é necessário mapear o seu arquivo TLD
11
22
33
44
55
66
77
88
99
10
10
11
11
12
12
13
13
14
14
15
15
16
16
17
17
18
18
19
19
20
20
21
21
<bean:define
<bean:define id="favs"
id="favs" name="FavoritesForm"/>
name="FavoritesForm"/>
<script
<script language="JavaScript">
language="JavaScript">
function
function showMessage()
showMessage() {{
alert(
alert( “Oi,
“Oi, <bean:write
<bean:write name='favs'
name='favs' property='name'/>!"
property='name'/>!" );
);
}}
</script>
</script>
<p>
<p>
Obrigado
Obrigado por
por responder,
responder, <bean:write
<bean:write name="favs"
name="favs" property="name"/>!
property="name"/>!
<br/>
<br/>
<a
<a href="javascript:showMessage()">Clique
href="javascript:showMessage()">Clique aqui</a>
aqui</a>
</p>
</p>
<p>Suas
<p>Suas cores
cores favoritas
favoritas indicadas
indicadas são:
são:
<ul>
<ul>
<li><bean:write
<li><bean:write name="favs"
name="favs" property="color[0]"/></li>
property="color[0]"/></li>
<li><bean:write
<li><bean:write name="favs"
name="favs" property="color[1]"/></li>
property="color[1]"/></li>
<li><bean:write
<li><bean:write name="favs"
name="favs" property="color[2]"/></li>
property="color[2]"/></li>
</ul>
</ul>
<ul>
<ul>
<c:forEach
<c:forEach var="color"
var="color" items="${favs.color}">
items="${favs.color}">
<li><c:out
<li><c:out value="${color}"/></li>
value="${color}"/></li>
</c:forEach>
</c:forEach>
120
Struts :: Plugins disponíveis (Extensivamente utilizados)
•
Tiles framework
•
•
Permite construção de páginas web através da montagem de tiles reutilizáveis
Facilidade de modificar o layout e conteúdo sem que um afete o outro
Geralmente o site está dividido entre Header, Body, Menu e Footer
• Template tanto para conteúdo estático como dinâmico, internationalização e outros.
•
•
Validator Framework
•
•
•
•
Incluido no Struts 1.1 por padrão
Originado a partir do framework Validator do Apache Jakarta
Evita uso de escrita no método validate() dentro do ActionForm (redundância)
Toda a regra de validação está inclusa dentro um arquivo de configuração XML
•
•
Pode estar incluso chamada a uma função javascript para fazer o tratamento necessário
Ambos devem ser configurado no [struts-config.xml] da aplicação
121
Struts :: Revisão Geral Arquitetura (Java EE x Struts 1.1)
122
Struts :: Boas práticas de programação (Parte 1)
01. Estruture os arquivos de configuração de acordo com a aplicação
# Utilize um arquivo tipo [struts-global.xml] para centralizar contexto genérico
# Neste caso crie um arquivo para cada entidade (struts-action-compras.xml)
+ Utilize um subdiretórios [compras] ou [struts-action] para centralizar o conteúdo
# Isto também vale para o uso dos validators caso esteja sendo utilizado
02. Utilize JSTL e o EL do JSP 2.0 em vez das talglibs logic e bean
# A própria comunidade do Struts recomenda, inclusive sub-projetos Struts-EL
03. Esqueça os arquivos TLD, eles já estão dentro dos JAR’s do struts
<%@ taglib prefix=“html” uri=“http://java.sun.com/jsp/jstl/core”/>
# Procurar TLD’s dentro de JAR’s é obrigatório desde especificação JSP 1.1
04. Evite <html:errors>. Geralmente utilizam como 1ª tag de aprendizado
Solução padrão é usar arquivo de mensagens [ApplicationResources.properties]
Consequentemente utilizando a tag <html:messagens> para mostrar o erro
<html:messages id=“error” property=“nome”>
<li>${error.usuario.naoEncontrado}
</html:messages>
123
Struts :: Boas práticas de programação (Parte 2)
05. Utilize Plug-in Validator(Integra código via javascript e ActionForm)
# O idéal é evitar regras individuais dentro do ActionForm, mas pode acontecer
# Geralmente utilizado para validações genéricas dentro do contexto da aplicação
06. Prefira DynaActionForm com todos os campos do tipo String
# Alternativa para muitas classes ActionForm’s dentro da aplicação
# Configurado dentro do struts-config.xml. Podem ser acessados via JSTL/EL JSP2
${nomeFormularioDinamico.map.propriedade}
:: Referência explícita ao atributo “map”
07. Aproveite a presença da API Commons BeanUtils da Jakarta
# API utilizada pelo struts e encontra-se dentro do arquivo commons-beanUtils.jar
# Utilização do método estático BeanUtils.copyProperties()
08. Utilize extensivamente a classe DispatchAction
# Tenha vários métodos dentro de um Action ao invés do tradicional execute()
# Lembrar de acrescentar o atributo parameter dentro do action-mapping
# Valor do parâmetro pode estar dentro da URL ou HEADER do formulário
124
Struts :: Boas práticas de programação (Parte 3)
09. Use o Struts para capturar todas as exceções necessárias da aplicação
# Recomendado utilizar excecções de runtime para erros de infra-esrtutura
# Para capturar utiliza-se [global-exceptions] dentro do [struts-config.xml]
10. Use logging sempre puder (Organize a estrutura da saída de mensagem)
# JSE 5.0 incorporou a API de Commons Logging da Jakarta (java.util.Logging)
# Estruture níveis de detalhação para debug, info, error, e outros da aplicação
# Bastante importante para verificação em ambientes de produção
11. Não inclua lógica de negócio nos Actions (Controller, lembra ?)
# Visualize o desenvolvimento dentro do modelo MVC
# Objetivo é obter os dados e despachar para a camada de negócios (Model)
12. Utilize os recursos de segurança declarativa do Java EE (web.xml)
# Os roles ficam definidos dentro do web.xml pelo security-constraint
# Dentro do action-mapping é possível verificar quais os roles com acesso
# Também pode ser verificado acesso dentro do JSP pela tag logic-present
# Vários tags do tiles suportam o atributo role
125
Struts :: Boas práticas de programação (Parte 4)
13. Não utilize o pool de conexões interno do Struts
# Na documentação é indicado como depracated a partir da versão 1.2.x
# Utilize o pool de conexões na arquitetura de sua aplicação
# Caso sua aplicação não possua uma sugestão seria o Jakarta Commons DBCP
14. Use o CSS nível 2(conhecido como layers) ou Tiles
# CSS (Cascading Style Sheets) resolve o problema de conteúdo e formatação
# Para o desenvolvedor a melhor alternativa é o Tiles, já o webdesigner CSS 2
15. Procure utilizar um projeto padão para testar novas funcionalidades
# O framework dispõe muitas funcionalidades e configurações
# Melhor testar e implementar em um projeto modelo de funcionalidades
16. Última dica para aproveitar o fim da página é usar práticas do TDD
# TDD (Test Driven Development) é uma das grandes práticas do XP
# Utilizando o conceito de integração contínua:
126
Struts 2.0 framework
(Struts +Webwork)
Apache Software Foundation
127
Struts 2 :: Introdução
Apache Struts 2 foi originalmente desenvolvido a partir do webwork 2
• Struts 2 requer pelo menos a API Servlet 2.4, JSP 2.0 e Java 5
• Actions agora são POJO’s e não estendem a API de servlet
•
•
Actions são configurados por pacote
Podem utilizar anotações ou arquivos de configuração em XML
• Suporte a temas e validações detalhadas e customizáveis
• Baseado no OGNL (Object Graph Navigation Language) :: EL Avançado
•
•
•
Fácil leitura, compilação incremental bastante rápida
Já vem embutido suporte com Freemarker, Velocity e JSP
•
Arquitetura foi projetada com suporte a plugins:
•
Tiles, JasperReports, JFreeChart, JSF, SiteMesh entre outros em andamento
Suporte nativo para AJAX com os toolkit’s DOJO e DWR
• Integração nativa com spring
•
128
Struts 2 :: Arquitetura Geral (Visão Genérica)
129
Struts 2 :: Comparativo Genérico (Diferenças quanto ao Struts1)
Implementações em Struts 1 continuarão funcionando
• Migração não é complexa, porém é trivial
• É notavel que antes o ActionServlet(Front Controller) agora é um Filter
• Freemarker é adotado como padrão, podendo ainda usar JSP ou velocity
• Exibe erros de maneira melhorada
• Sintaxe similar ao Velocity
• Support a JSP taglibs
•
130
Struts 2 :: Injeção de Dependência (Um conceito básico)
Utilizado manter baixo acoplamento entre componentes de sistema
• Dependências de módulos são definidas na configuração do sistema
•
•
•
•
Configuração a partir de uma infra-estrutura (container)
Estas dependências serão injetadas durante a instância da classe
Injeção de dependência é um tipo de inversão de controle
•
Existem duas formas de inversão de controle:
Dependency Lookup
• Injection Dependendy
•
Inversão de
Controle
Procura por
Dependência
Contextualized
Dependency
Lookup
Dependency
Pull
Injeção de
Dependência
Interface
Setter
Construtor
131
Struts 2 :: Classe Action (Introdução)
Os Actions agora são POJO’s. Devem obedecem o padrão Javabean
• Struts2 pode utilizar injeção de dependência para instanciar os Actions
• Dependências dos Actions sejam resolvidos no momento da instância
• Possibilidade de integração com frameworks Spring + Hibernate
• Existe também a utilização da técnica de binding (ValueStack)
• Possibilita uso de expressões a fim de buscar propriedades de objetos
• Os dados do request contrõem o POJO que é injetado no Action
• Exemplo de configuração de um action (struts.xml)
•
<struts>
<struts>
<include
<include file="struts-default.xml"/>
file="struts-default.xml"/>
<package
<package name="default“
name="default“ extends="struts-default">
extends="struts-default">
<action
<action name="Hello"
name="Hello" class="Hello">
class="Hello">
<result>/pages/Hello.jsp</result>
<result>/pages/Hello.jsp</result>
</action>
</action>
<!–
<!– adicione
adicione outros
outros actions
actions aqui
aqui -->
-->
</package>
</package>
</struts>
</struts>
132
Struts 2 :: Classe Action (Exemplo de Implementação)
•
ActionsForm (FormBeans) não são mais utilizados
•
•
•
Os testes tornaram-se mais fáceis.
Implementação não depende mais do container.
Exemplo de implementação de um Action
public
public class
class ListaUsuariosAction
ListaUsuariosAction {{
public
public Collection<Usuario>
Collection<Usuario> usuarios;
usuarios;
public
public String
String listaUsuarios()
listaUsuarios() {{
usuarios
usuarios == DAOService.getUsuarios();
DAOService.getUsuarios();
return
return “listaUsuarios”;
“listaUsuarios”;
}}
public
public Collection<Usuario>
Collection<Usuario> getUsuarios()
getUsuarios() {{
return
return usuarios;
usuarios;
}}
public
public void
void setUsuarios(Collection<Usuario>
setUsuarios(Collection<Usuario> usuarios)
usuarios) {{
this.usuarios
this.usuarios == usuarios;
usuarios;
}}
}}
133
Struts 2 :: Interceptors
Objetos java utilizados para execução antes ou depois dos Actions
• Alguns Interceptors interessantes
• Alias
•
•
•
Execute and Wait
•
•
Criará dentro da Action uma referência ao arquivo que
existe no request
Token
•
•
Rodar serviços em segundo plano, enquanto é mostrado
uma mensagem
File upload
•
•
Actions de atributos diferentes de nomes dos enviados
Permite que você mapeie uma exceção java para um result específico
Você pode implementar seus próprios interceptors a partir da interface:
• com.opensymphony.xwork.interceptor.Interceptor
134
Struts 2 :: Relação de Tags (Modelo Estrutural)
•
Struts Tags
•
•
Generic Tags :: UI Tags :: Themes e templates
AJAX Tags
•
•
Podem ser implementadas via JSP, Freemarker e Velocity
•
•
AJAX Tags :: Integração com DOJO e DWR
Em ambos os casos podem ser utilizados em conjunto com OGNL
Segue abaixo arquitetura básica de interface com usuário
135
Struts 2 :: Comparativo Relacional (Struts1 x Struts2 :: Parte 1)
Feature
Struts 1
Struts 2
Action classes
Classe Action impossibilitava estender outra classe
A classe Action é um POJO
Threading Model
Actions são classe singletons e devem ser thread-safe
desde que uma única instância da classe
manipule todas as requisições para o Action
Actions são instânciados para cada requisição.
Servlet Dependency
Actions possuem dependências da classe HttpServlet,
inclusive objetos Request e Response que são
passados no argumento do método execute.
Não possuem acoplamento da API de Servlets.
Testability
Dependem da API do Servlet pelo método execute()
Actions podem ser testados no momento da
instância, acessando suas propriedades,
invocando métodos via IoC.
Harvesting Input
No Struts 1 é utilizado ActionForm ou DynaBean
para capturar entrada de dados do formulário,
consequentemente criando redudâncias.
Struts 2 utilizam propriedades do Action para
acessar entradas de formulário. Essas
propriedades podem ser acessadas via taglib.
Também é suportado o uso dos ActionForm, em
conjunto com objetos Action POJO.
Expression Language
Possibilita integração com JSTL, sendo que é
utilizado apenas JSTL EL.
JSTL pode ser utilizado, mas atualmente dispõe
por padrão tanto com JSP, FreeMarker e
Velocity o uso implítico de OGNL.
136
Struts 2 :: Comparativo Relacional (Struts1 x Struts2 :: Parte 2)
Feature
Struts 1
Struts 2
Binding values into
views
Utiliza o mecanismo de JSP Standard dentro do
contexto de páginas para acessar objetos.
Utiliza tecnologia “ValueStack” que possibilita as
tags acessarem valores de objetos sem estar
diretamente acoplados com a visão do tipo
de objeto que está sendo renderizado.
ValueStack estrategicamente possibilita reuso de
visões acessando propriedades pelo mesmo
nome mesmo de tipos diferentes.
Type Conversion
Propriedades utilizadas em ActionForm usualmente
são todas do tipo String. Struts 1 utiliza a API
commons-beanUtils para efetuar a conversão
para um tipo de objeto em específico.
Struts 2 utiliza OGNL para tipos de conversões. O
framework inclui conversores básico para
tipo de objetos comuns e primitivos.
Validation
Suporte manualmente via método validate do
ActionForm ou através Commons Validator.
Foi estendido o uso do XWork Validator que
possibilita validações através de sub-objetos
usando validações definidas para diversos
tipos de propriedades e contextos.
Control of Action
Execution
Suporta separação do RequestProcessor (lifecycle)
para cada módulo, mas todos os actions dentro
do módulo devem compartilhar o mesmo ciclo
de vida definido.
Os Actions suportam diferentes ciclos de vida a
partir de Interceptors, inclusive podem ser
customizados.
137
Struts 2 :: Comparativo (Struts2 x WebWork2)
Webwork 2.2 propõe as mesmas funcionalidades do Struts 2.0
• Comparativo de organização estrutural entre o Struts2 e Webwork 2
•
138
AJAX
Asynchronous Javascript and XML
139
AJAX :: Aplicações web tradicionais
•
•
•
•
•
Web originalmente projetada para navegação de documentos HTML
Modelo “Clique, aguarde e recarregue” durante requisições
Página é recarregada a cada evento, envio de dados ou navegação
Existe a perda de contexto (informações mostradas anteriormente)
Modelo de comunicação síncrono
140
AJAX :: Rich Internet Application (RIA)
Conceito de aplicações web com características de uma desktop
• Programa responde de forma intuitiva e rápida
• Tudo acontece naturalmente (sem necessidade de um evento)
• Termo utilizado inicialmente pela Adobe(Macromedia) em 2001
• Alternativas de uso em busca do RIA
• Java Applet e/ou Java Web Start via JNPL
• DHTML = HTML + JavaScript + CSS + DOM
• Macromedia Flash
• DHTML com IFrame Oculto
• Laszlo ou Flex (Flash + comunicação assíncrona)
• AJAX (DHTML + XMLHttpRequest via comunicação assíncrona)
• Outros frameworks que se beneficiam do AJAX
•
•
•
(DWR, Dojo, jMaki, JSON, GWT, RichFaces, Dynafaces, Icefaces, ..... )
Hoje temos grandes inovações com o JavaFX e o Silverlight(Microsoft)
141
AJAX :: Rich Internet Application (RIA)
•
Exemplo de execução de modelo uma comunicação assíncrona
•
Não existe a interrupção do usuário enquanto os dados estão sendo
carregados. A renderização do conteúdo ocorre dinamicamente.
142
AJAX :: Introdução
Termo utilizado por Jesse James Garret em Fevereiro de 2005
• Principais características
• Modelo Assíncrono
• Interface mais natural e intuitiva (Melhor usabilidade)
• Atualização parcial da tela (Não existe a perda do contexto)
• Tecnologias utilizadas
• Protocolo HTTP
• DHTML = HTML + JavaScript + CSS + DOM
• Programação pelo lado do servidor
•
•
•
•
É necessário ativar/reativar uma chamada assíncrona para o servidor
Podem se utilizar Servlet’s, JSP, JSF, bem como frameworks como Struts
Utilização do objeto XMLHttpRequest
•
Atualmente fornece um melhor suporte por parte dos browser’s
143
AJAX :: Arquitetura e processo de comunicação
144
AJAX :: Comunicação HTTP via XMLHttpRequest
•
Diferenças entre aplicações web tradicionais das que usam AJAX
145
AJAX :: Comunicação HTTP via XMLHttpRequest
•
Diagrama de sequência a partir de uma requisição utilizando AJAX
146
AJAX :: Objeto XMLHttpRequest
Inicialmente implementado pela Microsoft dentro do IE5 (ActiveX)
• Engenheiros do Mozilla e Apple efetuaram uma versão nativa
• Consequentemente a W3C convergiu dentro de uma proposta
•
•
Document Object Model (DOM) Level 3 Load and Save Specification
Comunica-se GET/POST
• Content Type pode ser
•
•
•
•
•
•
text/xml
text/plain
text/json
Text/javascript
Pode ser utilizado em
outras tecnologias como
• ASP, PHP, Ruby, .NET
147
AJAX :: Fluxo de implementação (passo-a-passo)
•
Passos necessários para implementar uma aplicação com AJAX
148
AJAX :: Popularidade entre frameworks
•
Fonte
Ajaxian em 23 de Setembro de 2006
• Artigo do SEJug (Grupo de Usuários Java de Sergipe) sobre AJAX com DWR
•
149
Web 2.0 ?
150
Web 2.0 :: O que danado é isso ?
Termo idealizado por Tim O’Reilly em outubro de 2004
• A partir de uma série de conferências sobre desenvolvimento web
• O que faz de um site ou tecnologias ser web 2.0?
• Na verdade seguem algumas características
• Envolvimento com o usuário
• Conteúdo que importa
• Melhor organização de conteúdo
• Acessibilidade
• Velocidade
• Outros pontos
•
•
Resumidamente é um novo jeito
de desenvolver para web!
151
Web 2.0 :: O emergencial controle de massa de mídia social
152
Web 2.0 :: Potenciais benefícios da colaboração de negócios social
153
Web 2.0 :: Afinal o eles chamam de Enterprise 2.0 ?
154
Web 2.0 :: Novo ecossitema Web formalizado
155
Web 2.0 :: Efeitos entre sites
156
Web 2.0 :: Qual tendência nos próximos anos
157
Web 2.0 :: Alguns termos utilizados e envolvidos
158
Projeto :: Estudo de caso
Desenvolvendo conceitos práticos
159
Referências Bibliográficas
160