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
faelcavalcanti@gmail.com :: 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
Servlet’s Struts 1.1
e Protocolos

Evolução
JSP Struts 2.0
Arquitetura

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
• Protocolo através de texto ASCII e possuía único método [GET]
• 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]
• 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
• Não possui informação sobre os dados apresentados(diferente XML)
• Renderização do conteúdo ocorre na interpretação pelo browser
• Um arquivo HTML pode ter extensão .htm ou html
• 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
• 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
• Benefícios quanto a evolução das aplicações enterprises
• 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 :
u est
• Dificuldade de atualizações e manutenções re q
SQL o n se
• Alto acoplamento no modelo de dados L re s p
SQ
• Atualizações tornam-se custosas
T CP
• Cada cliente é comprometido /I P
TC
• Alto tráfico de rede P/
IP
• Transferência feita por poucos dados
• 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
• 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.
• Vasta quantidade de recursos disponíveis por diversas comunidades
• 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á exis-
tentes 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 • Java EE 5
• J2SE 1.4 (improved) • JAX-WS 2.0 & JSR 181
• JAX-RPC (new) • Java Persistence (JPA)
• Web Service for J2EE • EJB 3.0
• J2EE Management e Deployment • JAXB 2.0
• JMX 1.1 • JavaSever Faces 1.2 new
• JMS 1.1 • JSP 2.1
• JTA 1.0 • Others
• Servlet 2.4
• JSP 2.0
• EJB 2.1
• JavaMail 1.3

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
• Multiplataforma e tem praticamente toda a plataforma Java disponível
• Performace
• 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()
• Chamado uma única vez quando o servlet é carregado
• service()
• 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
• Possibilita guardar algum tipo de informação durante requisições
• Problema
• 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
• Exemplo do carrinho de compras
• Utilizar somente o necessário!
• Request :: javax.servlet.HttpRequest
• 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
• Um hacker poderia obter informações pessoais do usuário
• Geralmente configura-se o browser para desabilitar o uso de cookies
• Alternativas
• Utilizar a técnica do URL Rewriting
• 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
• Obter informações da aplicação durante determinados eventos
• Problema
• 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
Outros ciclo de vida de listeners
(não possui “Attribute” na classe)
Métodos de atributos de listeners
(exceto binding listeners)
Ciclo de eventos (Sessão)
(exceto eventos de atributos)
Ciclo de eventos (Request)
(exceto eventos de atributos)
Ciclo de eventos (Contexto)
(exceto eventos de atributos)
ServletRequestAttributeListener
ServletContextAttributeListener
HttpSessionAttributeListener
ServletRequestListener
ServletContextListener
HttpSessionListener
HttpSessionBindingListener
HttpSessionActivationListener
attributeAdded()
attributeRemoved()
attributeReplaced()
Quando o objeto Session é criada e quando é destruída
sessionCreated()
sessionDestroyed()
Quando o Request é inicializado ou destruído
requestInitialized()
RequestDestroyed()
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
• HTML, XML e textos entre as tags do formulário
• Conteúdo dinâmico
• 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)
• Forma simples de acessar objetos declarados em qualquer escopo da aplicação
• Propriedades poderão ser acessadas desde que esteja dentro do padrão JavaBean
• JSP Standard Action
• 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” %>
• Controla se o buffer de saída será flushed quando estiver cheio
• buffer :: <%@ page buffer=“32kb” %>
• Define o tamanho de buffer utilizado no JspWriter para o cliente em Kb
• contentType :: <%@ page contentType=“text/html” %>
• Identifica cabeçalho de resposta, indicando o tipo MIME enviado
• isErrorPage :: <%@ page isErrorPage=“false” %>
• 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” %>
• Indica a superclasse do servlet que será gerada a partir da página JSP
• Info :: <%@ page info=“Mensagem qualquer” %>
• Define uma string que será recuperada do servlet através do método
• session :: <%@ page session=“true” %>
• Define se a página utilizará algum recurso de sessão HTTP ou não
• isThreadSafe :: <%@ page isThreadSafe=“true” %>
• Define se o servlet irá implementar a interface SingleThreadModel
• language :: <%@ page language=“smaltalk” %>
• Utilizado para especificar a linguagem de programação base no JSP
• import :: <%@ page import=“java.util.Locale” %>
• 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:
• 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
• Nehuma destes itens acima é considerado uma boa prática
• 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
• pageScope Caso não seja explicitado o valor ele irá buscar dentro dos
Todos são objetos implícitos :: Map

• requestScope 4 escopos, uma referência com o name especificado.

• sessionScope Foi o caso do exemplo utilizando person!
• applicationScope

• param Java
Java Language
Language Naming
Naming Rules
Rules
1.
1. Pode
Pode iniciar
iniciar com
com letra,
letra, underline
underline ee dolar
dolar “$”
“$”
• paramValues
2.
2. Números
Números poderão
poderão aparecer
aparecer após
após letras
letras
• header 3.
3. Palavras
Palavras reservadas
reservadas não
não são
são permitidas
permitidas
• headerValues ----------
----------
Qualquer
Qualquer violação
violação destas
destas regras
regras uma
uma
exceção
exceção será
será levantada!
levantada!
• cookie
• initParam
De todos os objetos implícitos citados acima, somente
• pageContext 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 Referência do TLD no DD(web.xml)
<taglib
<taglib ....>
....> <web-app
<web-app ...>
...>
<tag>
<tag> <jsp-config>
<jsp-config>
<name>curso</name>
<name>curso</name> <taglib>
<taglib>
<tag-class>teste.Curso</tag-class>
<tag-class>teste.Curso</tag-class> <taglib-uri>curso</taglib-uri>
<taglib-uri>curso</taglib-uri>
<body-content>empty</body-content>
<body-content>empty</body-content> <taglib-location>
<taglib-location>
</tag>
</tag> /WEB-INF/tld/sample.tld
/WEB-INF/tld/sample.tld
</taglib>
</taglib> </taglib-location>
</taglib-location>
</taglib>
</taglib>
</jsp-config>
</jsp-config>
<web-app>
<web-app>

Classe estendida de TagSupport Arquivo JSP

public
public class
class Curso
Curso extends
extends TagSupport
TagSupport {{ <%@taglib
<%@taglib prefix="rafa“
prefix="rafa“ uri="curso"%>
uri="curso"%>
<html>
<html>
private
private PageContext
PageContext pageContext;
pageContext; <head>
<head>
<title>TagSupport</title>
<title>TagSupport</title>
public
public int
int doStartTag()
doStartTag() throws
throws JspException
JspException {{ </head>
</head>
try {
try { <body>
<body>
pageContext.getOut().print(“Hello”);
pageContext.getOut().print(“Hello”); <br/>
<br/>
}} catch
catch (IOException
(IOException e)
e) {{ <center>
<center>
throw new JspException(“erro");
throw new JspException(“erro"); <rafa:curso/>
<rafa:curso/>
}} return
return SKIP_BODY;
SKIP_BODY; </center>
</center>
}} </body>
</body>
public
public int
int doEndTag()
doEndTag() throws
throws JspException
JspException {{ </html>
</html>
return
return EVAL_PAGE;
EVAL_PAGE;
}}
}}
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
• Condições, Loop’s, switch, redirecionamentos, impressões e outros
• Database
• Acesso e manipulação de dados dentro de um JSP
• Cuidado com a arquitetura em camadas. Este não é o papel do JSP.
• Formatting
• Garante formatação de números, datas, entre outros campos customizáveis
• XML e XPath
• 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
<%
<% <c:out>
<c:out>
java.util.Iterator
java.util.Iterator ii == cartelas.iterator();
cartelas.iterator(); <c:set>
<c:set>
Cartela cartela = null;
Cartela cartela = null; <c:remove>
while(
<c:remove>
while( i.hasNext()
i.hasNext() )) {{ <c:if>
cartela
cartela == (Cartela)
(Cartela) i.hasNext();
i.hasNext();
<c:if>
%>
%>
<c:choose>
<c:choose>
<%=
<%= cartela.numero
cartela.numero %>
%> <c:when>
<c:when>
<%
<% }} %>
%> <c:otherwise>
<c:otherwise>
<c:forEach>
<c:forEach>
<c:import>
<c:import>
• Código utilizando TAG’s JSTL <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
<sql:setDataSource>
<sql:setDataSource>
• Consultas <sql:query>
<sql:query>
<sql:update>
• Atualizações
<sql:update>
<sql:param>
<sql:param>
• Transações <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
• 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

• Após excutado a regra, o Action controla esta delega a um JSP

• 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 javax.servlet.http.*;
javax.servlet.http.*;
import
import 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
HttpServletRequest request, HttpServletResponse response) {{
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
10 validate="true">
validate="true">
11
11 <forward
<forward name="success"
name="success" path="/submitSuccess.jsp"/>
path="/submitSuccess.jsp"/>
12
12 <forward
<forward name="failure"
name="failure" path="/submitFailure.jsp"/>
path="/submitFailure.jsp"/>
13
13 </action>
</action>
14
14
15
15 </action-mappings>
</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 String
String getName()
getName() {{ return
return this.Name
this.Name }}
public
public void
void setName(String name)
setName(String 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
• Suporte para renderização entre camada de visão e componentes DHTML
• struts-logic
• Disponibiliza tags lógicas dentro do JSP a fim de eliminar scriptlets
• struts-bean
• Tag responsável para acessar beans bem como suas propriedades
• struts-template
• 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 <bean:define
<bean:define id="favs"
id="favs" name="FavoritesForm"/>
name="FavoritesForm"/>
22 <script
<script language="JavaScript">
language="JavaScript">
33 function
function showMessage()
showMessage() {{
44 alert(
alert( “Oi,
“Oi, <bean:write
<bean:write name='favs'
name='favs' property='name'/>!"
property='name'/>!" );
);
55 }}
66 </script>
</script>
77 <p>
<p>
88 Obrigado
Obrigado por
por responder,
responder, <bean:write
<bean:write name="favs"
name="favs" property="name"/>!
property="name"/>!
99 <br/>
<br/>
10
10 <a
<a href="javascript:showMessage()">Clique
href="javascript:showMessage()">Clique aqui</a>
aqui</a>
11
11 </p>
</p>
12
12 <p>Suas
<p>Suas cores
cores favoritas
favoritas indicadas
indicadas são:
são:
13
13 <ul>
<ul>
14
14 <li><bean:write
<li><bean:write name="favs"
name="favs" property="color[0]"/></li>
property="color[0]"/></li>
15
15 <li><bean:write
<li><bean:write name="favs"
name="favs" property="color[1]"/></li>
property="color[1]"/></li>
16
16 <li><bean:write
<li><bean:write name="favs"
name="favs" property="color[2]"/></li>
property="color[2]"/></li>
17
17 </ul>
</ul>
18
18 <ul>
<ul>
19
19 <c:forEach
<c:forEach var="color"
var="color" items="${favs.color}">
items="${favs.color}">
20
20 <li><c:out
<li><c:out value="${color}"/></li>
value="${color}"/></li>
21
21 </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 Injeção de

Dependência Dependência

Contextualized Interface Setter Construtor

Dependency
Dependency
Pull
Lookup
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
• Actions de atributos diferentes de nomes dos enviados
• Execute and Wait
• Rodar serviços em segundo plano, enquanto é mostrado
uma mensagem
• File upload
• Criará dentro da Action uma referência ao arquivo que
existe no request
• Token
• 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
• AJAX Tags :: Integração com DOJO e DWR
• Podem ser implementadas via JSP, Freemarker e Velocity
• 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
Action classes Classe Action impossibilitava estender outra classe
Actions são classe singletons e devem ser thread-safe
Threading Model desde que uma única instância da classe
manipule todas as requisições para o Action
Actions possuem dependências da classe HttpServlet,
Servlet Dependency inclusive objetos Request e Response que são
passados no argumento do método execute.
Testability Dependem da API do Servlet pelo método execute()
No Struts 1 é utilizado ActionForm ou DynaBean
Harvesting Input para capturar entrada de dados do formulário,
consequentemente criando redudâncias.
Possibilita integração com JSTL, sendo que é
Expression Language
utilizado apenas JSTL EL.
Struts 2
A classe Action é um POJO
Actions são instânciados para cada requisição.
Não possuem acoplamento da API de Servlets.
Actions podem ser testados no momento da
instância, acessando suas propriedades,
invocando métodos via IoC.
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.
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

Utiliza tecnologia “ValueStack” que possibilita as
tags acessarem valores de objetos sem estar
diretamente acoplados com a visão do tipo
Binding values into Utiliza o mecanismo de JSP Standard dentro do
de objeto que está sendo renderizado.
views contexto de páginas para acessar objetos.
ValueStack estrategicamente possibilita reuso de
visões acessando propriedades pelo mesmo
nome mesmo de tipos diferentes.
Propriedades utilizadas em ActionForm usualmente
Struts 2 utiliza OGNL para tipos de conversões. O
são todas do tipo String. Struts 1 utiliza a API
Type Conversion commons-beanUtils para efetuar a conversão
framework inclui conversores básico para
tipo de objetos comuns e primitivos.
para um tipo de objeto em específico.
Foi estendido o uso do XWork Validator que
Suporte manualmente via método validate do possibilita validações através de sub-objetos
Validation ActionForm ou através Commons Validator. usando validações definidas para diversos
tipos de propriedades e contextos.
Suporta separação do RequestProcessor (lifecycle)
Os Actions suportam diferentes ciclos de vida a
Control of Action para cada módulo, mas todos os actions dentro
partir de Interceptors, inclusive podem ser
Execution do módulo devem compartilhar o mesmo ciclo
customizados.
de vida definido.

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