1 - UFSC

UNIVERSIDADE FEDERAL DE SANTA CATARINA
Aplicações Ricas com Ajax
Ulysses Kuntze
Florianópolis - SC
2008/01
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE SISTEMAS DE INFORMAÇÃO
Aplicações Ricas com Ajax
Ulysses Kuntze
Trabalho de conclusão de
curso apresentado como parte
dos requisitos para obtenção
do grau de Bacharel em
Sistemas de Informação.
Florianópolis - SC
2008/01
Ulysses Kuntze
Aplicações Ricas com Ajax
Trabalho de conclusão de curso apresentado como parte dos
requisitos para obtenção do grau de Bacharel em Sistemas de
Informação.
Orientador:
_________________________________
Rogério Cid Bastos
Banca Examinadora: _________________________________
Fernando Ostuni Gauthier
_________________________________
Masanao Ohira
Agradecimentos
Agradeço a minha família, pelo apoio e motivação.
Agradeço ao Rogério, Cislaghi, Marta e Mauro pela paciência e
indispensável ajuda.
Muito obrigado a todos vocês.
Sumário
Lista de Figuras .................................................................................................. 9
Lista de Quadros .............................................................................................. 11
Lista de Tabelas ............................................................................................... 13
Lista de Reduções............................................................................................ 14
Resumo ............................................................................................................ 15
1
Introdução ................................................................................................. 16
1.1
Considerações Iniciais ....................................................................... 16
1.2
Justificativa ........................................................................................ 17
1.3
Objetivos ............................................................................................ 17
1.3.1
Objetivo Geral ............................................................................. 17
1.3.2
Objetivos Específicos .................................................................. 17
1.4
2
3
Limitações .......................................................................................... 18
Repensando o modelo de interatividade Web ........................................... 18
2.1
Clientes ricos ..................................................................................... 19
2.2
Comparando as experiências do usuário ........................................... 19
2.3
Latência de rede ................................................................................ 20
2.4
Interações assíncronas ...................................................................... 21
2.5
Padrões de uso soberano e transitório .............................................. 23
2.6
Desaprendendo a Web ...................................................................... 24
Ajax ........................................................................................................... 24
3.1
Os quatro princípios definidores do Ajax............................................ 25
3.1.1
O navegador hospeda uma aplicação, não o conteúdo. ............. 25
3.1.2
O servidor fornece dados, não conteúdo. ................................... 28
3.1.3
A interação do usuário com a aplicação pode ser fluente e
contínua 30
3.1.4
3.2
Uma codificação real requer disciplina ....................................... 32
Ajax no mundo real ............................................................................ 33
3.2.1
Google Maps............................................................................... 34
3.2.2
Google Mail ou GMail ................................................................. 37
3.2.3
Desktop Online ........................................................................... 39
3.2.4
Google Docs ............................................................................... 41
3.3
Alternativas ao Ajax ........................................................................... 43
3.3.1
Adobe Flash, Adobe Flex e Laszlo ............................................. 43
3.3.2
Java Web Start e Microsoft No Touch Deployment .................... 44
3.4
Os elementos-chave do Ajax ............................................................. 45
3.4.1
Orquestrando a experiência do usuário com JavaScript ............. 47
3.4.2
Definindo a aparência e o comportamento com CSS ................. 48
3.4.2.1
Seletores CSS ..................................................................... 49
3.4.2.2
Propriedades de estilo CSS ................................................. 52
3.4.3
Organizando a interface usando DOM ........................................ 53
3.4.3.1
3.4.3.1.1
Localizando um nó DOM .................................................. 55
3.4.3.1.2
Criando um nó DOM ......................................................... 56
3.4.3.1.3
Adicionando estilos ao documento ................................... 57
3.4.3.1.4
Utilizando a propriedade InnerHTML ................................ 58
3.4.4
Carregando dados assincronamente .......................................... 58
3.4.4.1
IFrames................................................................................ 59
3.4.4.2
Objetos XMLDocument e XMLHttpRequest......................... 60
3.4.4.3
Enviando uma solicitação para o servidor ........................... 61
3.4.4.4
Usando funções de retorno de chamada ............................. 62
3.4.5
3.5
Trabalhando com DOM utilizando JavaScript ...................... 55
Ciclo de vida completo ................................................................ 64
JSON ................................................................................................. 68
3.5.1
O Objeto Literal JavaScript ......................................................... 68
3.5.2
O que é JSON............................................................................. 69
3.5.2.1
Objeto .................................................................................. 70
3.5.2.2
Array .................................................................................... 71
3.5.2.3
Valor .................................................................................... 71
3.5.2.4
String ................................................................................... 73
3.5.2.5
Número ................................................................................ 74
3.5.3
Parsers JSON ............................................................................. 74
3.5.4
JSON vs XML ............................................................................. 76
3.6
O que diferencia o Ajax ...................................................................... 77
3.7
Vantagens e desvantagens ................................................................ 80
3.7.1
Vantagens ................................................................................... 80
3.7.1.1
Vantagens com relação à usabilidade ................................. 80
3.7.1.1.1
Tempos de espera mais curtos ........................................ 81
3.7.1.1.2
Validações automáticas em formulários ........................... 81
3.7.1.1.3
Páginas de confirmação ................................................... 82
3.7.1.1.4
Operações de Mestre-detalhe .......................................... 82
3.7.1.1.5
Autocompletar em campos de formulário ......................... 83
3.7.1.1.6
Manipulação de dados mais interativa ............................. 83
3.7.1.1.7
Navegação em estruturas hierárquicas profundas ........... 83
3.7.1.1.8
Interação do usuário com a aplicação .............................. 84
3.7.1.1.9
Rápida interação entre usuários ....................................... 84
3.7.1.1.10
Avançados controles e UI Widgets ................................. 84
3.7.1.1.11
Recarregamento de informações ................................... 84
3.7.1.2
Desempenho e compatibilidade........................................... 85
3.7.1.3
Dispositivos móveis ............................................................. 86
3.7.1.4
Web Standards .................................................................... 86
3.7.1.5
Independência de tecnologia do lado servidor..................... 86
3.7.1.6
Inúmeros frameworks de qualidade ..................................... 86
3.7.1.7
Adoção maciça da indústria ................................................. 87
3.7.2
Desvantagens ............................................................................. 87
3.7.2.1
Desvantagens em relação à usabilidade ............................. 87
3.7.2.1.1
Botão voltar e favoritos ..................................................... 87
3.7.2.1.2
Feedback ao usuário ........................................................ 87
3.7.2.1.3
Scrolling ............................................................................ 88
3.7.2.1.4
Rompimento das convenções existentes ......................... 88
3.7.2.1.5
Indexação ......................................................................... 88
3.7.2.1.6
Percepção do usuário ....................................................... 88
3.7.2.1.7
Eliminar aceitação ............................................................ 89
3.7.2.1.8
Quebrar o foco do usuário ................................................ 90
3.7.2.2
Desvantagens em relação à implementação ....................... 90
3.7.2.2.1
Aumenta a quantidade dos testes .................................... 90
3.7.2.2.2
Adiciona complexidade ..................................................... 91
3.7.2.2.3
Debuging difícil ................................................................. 91
3.7.2.2.4
Código-fonte fácil de pegar............................................... 91
3.7.2.2.5
Disponibilidade do objeto XMLHttpRequest ..................... 92
3.7.2.2.6
Sobrecarga do servidor .................................................... 92
3.7.2.2.7
3.8
Segurança .......................................................................................... 93
3.8.1
4
5
Lidando com assincronia .................................................. 93
Formas de Interação de uma Aplicação Ajax ............................. 94
A Aplicação UFSC Maps ........................................................................... 95
4.1
Tecnologias Empregadas .................................................................. 96
4.2
Telas .................................................................................................. 96
4.2.1
Tela Principal .............................................................................. 96
4.2.2
Tela de Cadastro ...................................................................... 100
4.2.2.1
Cadastro de Marcador ....................................................... 100
4.2.2.2
Cadastro de Polígono ........................................................ 102
Conclusão ............................................................................................... 103
5.1
Considerações finais ........................................................................ 103
5.2
Sugestões para futuros trabalhos .................................................... 103
Referências Bibliográficas .............................................................................. 105
Apêndice A
A.1
Ferramentas .......................................................................... 107
IDEs e IDEs Plugins ......................................................................... 107
A.1.1
Aptana ...................................................................................... 107
A.1.2
JSEclipse .................................................................................. 108
A.1.3
MyEclipse ................................................................................. 109
A.2
DOM Inspectors ............................................................................... 110
A.2.1
Firefox DOM Inspector .............................................................. 110
A.2.2
Internet Explorer Developer Toolbar ......................................... 111
A.3
Debuggers ....................................................................................... 112
A.3.1
Venkman JavaScript Debugger ................................................ 112
A.3.2
Firebug debug extension for Firefox ......................................... 113
A.4
Javascript Unit-Testing..................................................................... 114
A.4.1
Scriptaculous Unit-Testing ........................................................ 114
A.4.2
JsUnit (Hieatt) ........................................................................... 114
A.4.3
JsUnit (Schaible) ....................................................................... 115
Apêndice B
Frameworks e bibliotecas ...................................................... 116
B.1
Dojo.................................................................................................. 116
B.2
ExtJS................................................................................................ 116
B.3
Yahoo! UI ......................................................................................... 116
B.4
Prototype.......................................................................................... 117
B.5
Script.aculo.us ................................................................................. 117
B.6
JQuery ............................................................................................. 117
B.7
Mochikit ............................................................................................ 117
B.8
OpenRico ......................................................................................... 118
B.9
Quooxdoo ........................................................................................ 118
B.10
Mootools ....................................................................................... 118
B.11
Ruby on Rails ............................................................................... 118
B.12
DWR - Direct Web Remoting ........................................................ 119
B.13
GWT - Google Web Toolkit .......................................................... 119
Anexos ........................................................................................................... 120
Lista de Figuras
Figura 1
Ciclo de vida típico de uma aplicação Web clássica [3]. ................ 26
Figura 2
Ciclo de vida de um aplicativo Ajax [3]. .......................................... 27
Figura 3
Distribuição do conteúdo entregue (A) por um aplicativo Web
clássico e (B) por um aplicativo Ajax. A medida que o aplicativo continua a ser
utilizado, aumenta o tráfego acumulado (C). .................................................... 29
Figura 4
Página inicial do Google Maps. ...................................................... 35
Figura 5
Pop-up aberta ao clicar em um item do resultado da pesquisa. ..... 36
Figura 6
Interface do GMail com apresentação de mensagens de forma
escalonada, mensagens instantâneas e corretor ortográfico. .......................... 38
Figura 7
Protopage ....................................................................................... 40
Figura 8
Goowy ............................................................................................ 40
Figura 9
Online Operating System ............................................................... 41
Figura 10
Página Inicial do Google Docs .................................................... 42
Figura 11
Planilha do Google Docs. ........................................................... 42
Figura 12
Os quatro componentes principais do Ajax [3]. ........................... 46
Figura 13
O DOM representa um documento HTML em forma de arvore. . 54
Figura 14
Seqüência de eventos em uma comunicação assíncrona [3]. .... 60
Figura 15
Resultado da execução da solicitação visualizado no Internet
Explorer.
66
Figura 16
Resultado da execução da solicitação visualizado no Mozilla
Firefox.
66
Figura 17
Objeto em notação JSON ........................................................... 70
Figura 18
Array em notação JSON ............................................................. 71
Figura 19
Valor em notação JSON ............................................................. 72
Figura 20
String em notação JSON ............................................................ 73
Figura 21
Número em notação JSON ......................................................... 74
Figura 22
Uma página com componentes Ajax embutidos [3]. ................... 78
Figura 23
Uma aplicação Ajax em que ilhas de conteúdo do tipo documento
podem ser carregadas ou declaradas programaticamente. ............................. 79
Figura 24
Validação automática no servidor de nome de usuário em
formulário
81
9
Figura 25
Exemplo de operação mestre-detalhe ........................................ 82
Figura 26
Exemplo de autocompletar em campo no Google GMail. ........... 83
Figura 27
Exemplo de busca de informações atualizadas no servidor. ...... 85
Figura 28
Exemplos de feedback ao usuário .............................................. 88
Figura 29
Comparativo entre os modelos de interação .............................. 89
Figura 30
Focando a percepção as áreas atualizadas de forma sutil ......... 89
Figura 31
Tela inicial da aplicação. ............................................................. 97
Figura 32
Menu de mapeamentos expandido. ............................................ 98
Figura 33
Toolbar com botões selecionados. ............................................. 99
Figura 34
Tela de atualização de marcador. ............................................. 100
Figura 35
Tela de cadastro de marcador. ................................................. 101
Figura 36
Tela de cadastro de polígono.................................................... 102
Figura 37
Aptana Studio IDE .................................................................... 108
Figura 38
JSEclipse .................................................................................. 109
Figura 39
MyEclipse ................................................................................. 110
Figura 40
Firefox DOM Inspector .............................................................. 111
Figura 41
Internet Explorer Toolbar .......................................................... 112
Figura 42
Venkman JavaScript Debugger ................................................ 113
Figura 43
Firebug ...................................................................................... 114
10
Lista de Quadros
Listagem 1
Exemplo de seletor e declaração de estilo. ................................ 49
Listagem 2
Seletor por tipo de tag HTML. ..................................................... 49
Listagem 3
Seletor por tipo de classe declarada. .......................................... 50
Listagem 4
Atribuição de classe de estilo...................................................... 50
Listagem 5
Estilo textolaranja........................................................................ 50
Listagem 6
Elemento com mais de uma classe de estilo. ............................. 50
Listagem 7
Combinação de classes com regras baseadas em elementos. .. 51
Listagem 8
Seletor por ID único de elemento................................................ 51
Listagem 9
Pseudo-seletores. ....................................................................... 51
Listagem 10
Exemplo de propriedades para estilização de fontes. ............. 52
Listagem 11
Exemplo de propriedades para estilização de layout .............. 52
Listagem 12
Propriedade background-image. ............................................. 53
Listagem 13
Atribuição de ID a um elemento DOM. .................................... 55
Listagem 14
O método getElementById(). ................................................... 55
Listagem 15
A propriedade childNodes. ...................................................... 56
Listagem 16
O método createElement(). ..................................................... 56
Listagem 17
O método createTextnode(). ................................................... 57
Listagem 18
O método appendChild(). ........................................................ 57
Listagem 19
A propriedade className. ...................................................... 57
Listagem 20
A propriedade style. ................................................................ 58
Listagem 21
A propriedade innerHTML. ...................................................... 58
Listagem 22
Exemplo de função de criação do objeto XMLHttpRequest. ... 61
Listagem 23
Exemplo
de
envio
de
solicitação
através
do
objeto
XMLHttpRequest. 62
Listagem 24
Exemplo de rotina de retorno de chamada. ............................ 63
Listagem 25
Exemplo de ciclo de vida completo de carga de um documento.
64
Listagem 26
Arquivo XML retornado como resposta no exemplo ................ 67
Listagem 27
Método onReadyState modificado para receber uma resposta
em XML
67
Listagem 28
Método toConsole modificado para receber uma resposta em
XML
67
11
Listagem 29
Requisição pedindo um arquivo XML ...................................... 68
Listagem 30
Exemplo de objeto literal JavaScript ....................................... 69
Listagem 31
Exemplo de um objeto em notação JSON .............................. 70
Listagem 32
Exemplo de um array em notação JSON ................................ 71
Listagem 33
Exemplo de valores e estruturas aninhadas em notação JSON
72
Listagem 34
Exemplo de string em notação JSON ..................................... 73
Listagem 35
Conteúdo do arquivo json.txt ................................................... 75
Listagem 36
Método onReadyState modificado para receber uma resposta
JSON
75
Listagem 37
Método toConsole modificado para receber um parâmetro
JSON
75
Listagem 38
Requisição de resposta em formato JSON ............................. 76
Listagem 39
Exemplo em formato XML ....................................................... 76
Listagem 40
Exemplo em formato JSON ..................................................... 76
12
Lista de Tabelas
Tabela 1
Os elementos-chave do Ajax .......................................................... 45
Tabela 2
Vulnerabilidades por tipo de interação. .......................................... 94
13
Lista de Reduções
API
Application Programming Interfaces
CSS
Cascading Style Sheets
DOM
Document Object Model
HTML
HyperText Markup Language
HTTP
Hypertext Transfer Protocol
IDE
Integrated Development Enviroment
JSON
JavaScript Object Notation
MIME
Multipurpose Internet Mail Extensions
RIA
Rich Internet Application
RPC
Remote Procedure Call
RSS
Really Simple Syndication
UFSC
Universidade Federal de Santa Catarina
UI
User Interface
URL
Uniform Resource Locator
Web
World Wide Web
W3C
World Wide Web Consortion
WYSIWYG What You See Is What You Get
XHTML
Extensible HyperText Markup Language
XML
Extensible Markup Language
XSLT
Extensible Stylesheet Language Transformation
14
Resumo
A indústria se reinventa, conceitos e fundamentos pré-existentes são lançados
novamente ao mercado sob uma nova ótica. Iniciativas como Gmail, Google
Maps, Netvibes, Meebo, entre outras, despertaram a atenção de milhares de
desenvolvedores, que começam a reavaliar o processo de criação de interfaces
e aplicações Web. Em paralelo, a forma como os sistemas são projetados
também passa por mudanças profundas conceituais. A euforia sobre estes
conceitos, mais especificamente Web 2.0, RIA e Ajax, traz à tona novas
oportunidades.
Este trabalho tem por objetivo apresentar os conceitos, objetivos, tecnologias e
demais questões envolvidas na abordagem de desenvolvimento de aplicações
Web
conhecida
como
Ajax.
E
prover
uma
aplicação
Web
de
georeferenciamento do campus da UFSC utilizando a abordagem Ajax.
Palavras-chave: Ajax, RIA, Web 2.0, Desenvolvimento Web, DOM, CSS,
XMLHttpRequest, JSON
15
1 Introdução
1.1 Considerações Iniciais
A indústria se reinventa: conceitos e fundamentos pré-existentes são lançados
novamente ao mercado sob uma nova ótica. A euforia sobre estes conceitos,
mais especificamente Web 2.0, RIA e Ajax, traz à tona novas oportunidades,
em diferentes nichos, e faz alusão à bolha em meados de 2000 1.
Este novo movimento está centrado em soluções focando uma só idéia: mudar
o paradigma de como enxergamos a Web. Esta passará a ser plataforma e não
somente meio [8].
Até os tempos atuais, o paradigma que orientou muitas iniciativas na Web foi
utilizá-la como meio de comunicação, prospecção de clientes, disseminação de
campanhas e afins. Utilizá-la como plataforma de operações era até o presente
momento inviável, por questões meramente oftalmológicas: miopia estratégica
das empresas [1].
Nos dias atuais, grandes partes das atividades computacionais dos usuários
estão ocorrendo via Web, e com isto, cada vez mais e mais empresas estão
disponibilizando versões Web de seus aplicativos tradicionalmente desktops.
Iniciativas como Gmail2, Google Maps3, Netvibes4, Meebo5, entre outras,
despertaram a atenção de milhares de desenvolvedores, que começam a
reavaliar o processo de criação de interfaces e aplicações Web.
Em paralelo, a forma como os sistemas são projetados também passa por
mudanças profundas conceituais, gerando assim inúmeras possibilidades
inovadoras ao mercado.
1
10 de Março de 2000, dia em que o índice NASDAQ atingiu seu pico máximo.
2
Disponível em http://mail.google.com.
3
Disponível em http://maps.google.com.
4
Disponível em http://www.netvibes.com/.
5
Disponível em http://www.meebo.com/.
16
1.2 Justificativa
O Ajax atende a uma necessidade do mercado para clientes baseados na Web
mais ricos e mais responsivos e que não precisam de nenhuma instalação
local. O Ajax é capaz de entregar tudo isto utilizando apenas as tecnologias já
instaladas na maioria dos navegadores Web modernos, sem a necessidade de
instalação de plug-ins6 ou outros recursos adicionais.
Com o Ajax, pegamos algumas tecnologias antigas e as estendemos muito
além de seu escopo inicial.
1.3 Objetivos
A seguir serão apresentados os objetivos do presente trabalho.
1.3.1 Objetivo Geral
Apresentar os conceitos, objetivos, tecnologias e demais questões envolvidas
na abordagem de desenvolvimento de aplicações Web conhecida como Ajax.
Prover uma aplicação Web utilizando a metodologia Ajax. A aplicação tem
como escopo prover o georeferenciamento do campus da UFSC utilizando a
API Google Maps7.
1.3.2 Objetivos Específicos
Para atingir o objetivo geral supracitado, neste trabalho serão explanados os
seguintes tópicos:

Origem e definição do termo;

Objetivos, vantagens, desvantagens sob as perspectivas da usabilidade
e do desenvolvimento;

Diferenças entre a abordagem tradicional e a abordagem Ajax para a
construção de aplicações Web;
6
Plug-in é um programa de computador que serve normalmente para adicionar funções a
outros programas maiores, provendo alguma funcionalidade especial ou muito específica.
7
Disponível em http://code.google.com/apis/maps/.
17

Apresentação das tecnologias que compõe Ajax e o modo como estas
tecnologias agem em conjunto;

Aplicações do mundo real que utilizam Ajax;

Frameworks e ferramentas que auxiliam o desenvolvimento de
aplicações Ajax.
Para colocar em prática os conhecimentos apresentados, será construída uma
aplicação Web desenvolvida utilizando a abordagem Ajax.
Esta aplicação terá como escopo o georeferenciamento do campus da UFSC.
E tem por objetivo dar uma nova opção de visualização para o mapa da UFSC,
atualmente um arquivo no formato PDF, estático, disponível no site da
instituição no endereço http://www.ufsc.br/páginas/mapa_ufsc.php.
1.4 Limitações
A aplicação de georeferenciamento do campus da UFSC irá prover
mecanismos
para
o
cadastro
dos
pontos
de
interesse
a
serem
georeferenciados. Este trabalho não tem por objetivo o mapeamento e cadastro
de todos os pontos de interesse, e sim o de fornecer os mecanismos para que
os mesmos possam ser cadastrados por terceiros.
2 Repensando o modelo de interatividade Web
Idealmente uma interface com o usuário (user interface - UI) deve ser invisível
aos usuários, fornecendo apenas a opções de que eles precisam quando
necessário ou, de outro modo, ficando fora do caminho, deixando-os livres para
focalizarem o problema em questão.
Infelizmente, isto é muito difícil de conseguir, assim, nós nos acostumamos, ou
nos resignamos, a trabalhar diariamente com UIs improdutivas, até que alguém
mostre uma maneira mais adequada para que possamos perceber o quão
frustrante nosso método atual de fazer as coisas pode ser.
A Internet atualmente está passando por este tipo de situação, uma vez que as
tecnologias básicas dos navegadores Web utilizadas para exibir conteúdo de
18
documentos estão além do limite daquilo que elas podem alcançar de uma
maneira sensata.
O aplicativo Web clássico com que estamos acostumados começa a se
quebrar sob o esforço que os serviços baseados na Web, cada vez mais
sofisticados, impõem sobre ela. Uma variedade de tecnologias está sendo
convocada a preencher a lacuna com clientes mais ricos, mais inteligentes e
mais aprimorados.
2.1 Clientes ricos
“Rico” se refere ao modelo de interação do cliente. Um modelo de interação
rica com o usuário é aquele que pode suportar uma variedade de métodos de
entrada e que responde de maneira intuitiva e no momento oportuno. Em
outras palavras, para que a interação com o usuário seja rica, ela deve ser tão
boa quanto à geração atual dos aplicativos desktop, como editores de texto e
planilhas.
2.2 Comparando as experiências do usuário
Observando uma aplicação desktop típica como um editor de planilhas ou um
gerenciador de e-mails, nota-se que o programa responde intuitivamente e
rapidamente, dando feedbacks8 significativos e instantâneos ao usuário como:
o cursor mudar de forma, ícones e botões se realçarem ao cursor passar sobre
os mesmos, textos selecionados mudam de cores, janelas são destacadas, os
diálogos foram representados de uma maneira diferente e assim por diante. As
coisas acontecem naturalmente sem a necessidade de se clicar em nenhum
botão ou hyperlink9. Isto pode ser definido como uma experiência de
interatividade rica para o usuário.
Agora, ao se analisar as características de uma aplicação Web convencional,
temos o modelo de interação com o usuário definido como: "clicar e esperar até
8
Provimento de informação sobre o estado de um sistema.
9
Hyperlink ou link é uma referência num documento em hipertexto a outro documento ou a
outro recurso.
19
carregar a nova página". Este processo de carregamento da página pelo
navegador Web é necessário para todos os eventos, submissões de dados e
navegação. O usuário sempre precisa esperar pela resposta, pois o modelo de
comunicação é baseado em requisição e resposta dirigido a páginas, e todo
este fluxo é definido no servidor. Por mais ricas e interligadas que sejam as
informações que estejam sendo visualizadas, a única maneira de interagir com
as mesmas é clicando nos hyperlinks ou preenchendo formulários de texto, e
ao realizar tais ações o foco na atividade anterior é perdida por alguns
instantes até que a próxima página seja carregada.
Comparado com o editor de planilhas, o modelo de interação em que a
aplicação Web convencional se baseia é inegavelmente limitado. Estas
limitações estão presentes nas aplicações Web convencionais devido a
inúmeras razões técnicas, sendo apresentadas algumas a seguir.
2.3 Latência de rede
A visão grandiosa da era da Internet é que todos os computadores do mundo
estão interconectados como um único grande recurso de computação.
Chamadas de procedimentos remotos (Remote Procedure Call - RPC) e locais
tornam-se indistinguíveis e os emissores nem mesmo estão cientes da
máquina física em que eles estão trabalhando.
Infelizmente
chamadas
de
procedimento
remotas
e
locais
não
são
absolutamente a mesma coisa. Comunicações em uma rede são caras, isto é,
elas são lentas e não confiáveis. Fazer uma chamada através de uma rede
nunca será tão eficiente quanto chamar um método local na memória. Além
disso, a não-confiabilidade da rede e daí a necessidade de reenviar pacotes
perdidos de informações, torna esta ineficiência variável e difícil de prever.
Uma UI bem-sucedida precisa simular nossas expectativas o mundo real em
um nível muito básico. Uma das regras fundamentais mais básicas da
interação é que, quando pressionamos, selecionamos ou apontamos para algo,
este responde imediatamente. Pequenos retardos entre apontar para algo e a
resposta pode distrair o usuário, desvirtuando a atenção do usuário a tarefa em
questão para a própria UI.
20
Ter de fazer todo este trabalho extra para atravessar a rede é na maioria das
vezes suficiente para diminuir a velocidade de um sistema a tal ponto que o
retardo torna-se perceptível. Em uma aplicação desktop precisamos tomar
decisões de projeto ruins quanto à usabilidade para fazer com que o aplicativo
seja falho ou não responsivo, mas em um aplicativo de rede podemos obter
tudo isso gratuitamente.
Devido à imprevisibilidade da latência de rede, este estado falho perceptível
aparecerá e desaparecerá, e testar a responsividade do aplicativo também
pode ser mais difícil. Daí a latência de rede ser uma causa comum da pobre
interatividade de aplicativos do mundo real.
Há somente uma resposta sensata ao problema da latência de rede disponível
para o desenvolvedor de UI, supor o pior. Em termos práticos, precisamos
tentar fazer as UIs responderem independentemente da atividade de rede.
Felizmente, uma resposta sustentável com freqüência é suficiente, contanto
que seja oportuna.
2.4 Interações assíncronas
Com qualquer UI, é uma pratica bem estabelecida gerar uma thread10
assíncrona para tratar qualquer computação demorada e deixá-la em execução
no segundo plano enquanto o usuário faz outras coisas. O usuário
necessariamente permanece bloqueado enquanto esta thread é carregada,
mas isso pode ser feito em um período de tempo aceitavelmente curto. Devido
à latência de rede, uma boa pratica é tratar qualquer RPC como
potencialmente demorada e tratá-la assincronamente.
Mas existe um problema. O HTTP é um protocolo de solicitação-resposta. Isto
é, o cliente emite uma solicitação a um documento e o servidor responde,
entregando o documento, informando que ele não pode localizá-lo, oferecendo
uma localização alternativa, ou instruindo o cliente a utilizar sua copia
10
É uma forma de um processo dividir a si mesmo em duas ou mais tarefas que podem ser
executadas simultaneamente.
21
armazenada em cache11 e assim por diante. Um protocolo de solicitaçãoresposta é de uma via. O cliente pode fazer contato com o servidor, mas o
servidor não pode iniciar uma comunicação com o cliente. De fato, o servidor
não se lembra do cliente entre uma solicitação e outra.
A maioria dos desenvolvedores Web que usam linguagens modernas como
Java, PHP ou .NET estão familiarizados com o conceito de sessões do usuário.
Estas são desenvolvimentos posteriores introduzidos nos servidores Web para
fornecer o estado das sessões anteriores do lado servidor no protocolo HTTP.
O HTTP faz aquilo pra o qual foi originalmente e muito bem projetado, e ele foi
adaptado para ir muito além desse ponto com uma engenhosidade
considerável. Entretanto, o recurso-chave da nossa solução ao retorno de
chamada assíncrona é que o cliente é notificado duas vezes: uma vez quando
a thread é iniciada e a outra quando a thread é completada. O HTTP simples e
direto e o modelo clássico de aplicativo Web é que não podem fazer isto
automaticamente.
O modelo clássico das aplicações Web ainda é construído em torno da noção
de páginas. Um documento é exibido para o usuário contendo listas de links
e/ou elementos de formulário que permitem que eles pesquisem outros
documentos.
Ao longo dos anos esta modelo de interação ficou profundamente enraizada
em nossa maneira de se pensar a Internet comercial e cotidiana. Ferramentas
de autoria Web amigáveis e do tipo WYSIWYG (What You See Is What You
Get – o que você vê é o que será impresso) visualizam nosso site como uma
coleção de páginas. Estruturas Web de lado servidor modelam a transição
entre páginas como diagramas de transição de estado. O aplicativo Web
clássico está firmemente associado à falta de responsividade quando a página
é atualizada, sem um recurso fácil a solução de tratamento assíncrono.
Mas para entender porque o modelo de aplicativo Web clássico funciona muito
bem até hoje para a maioria das pessoas devemos levar em conta os padrões
de uso.
11
No caso dos navegadores Web, é um diretório em que as páginas são guardadas localmente
para evitar consultas constantes à rede.
22
2.5 Padrões de uso soberano e transitório
Alan Cooper, um especialista em usabilidade de software, definiu dois modos
principais de uso: transitório e soberano. Um aplicativo transitório poderia ser
utilizado todos os dias, mas somente esporadicamente, em geral, como uma
atividade secundaria. Um aplicativo soberano, ao contrario, precisa lidar com
toda a interatividade do usuário por várias horas em um dado momento [2].
Muitos aplicativos são inerentemente transitórios ou soberanos. Por exemplo,
um editor de texto para um escritor é um aplicativo soberano no qual algumas
atividades
transitórias
girarão,
como
o
gerenciador
de
arquivos
(frequentemente embutido no editor como um diálogo para salvar ou abrir
arquivos), um dicionário ou corretor ortográfico e um programa de correio
eletrônico ou de mensagens para comunicação com colegas. Para o
desenvolvedor de software o ambiente integrado de desenvolvimento
(Integrated Development Environment - IDE) é soberano, assim como o é o
depurador12.
Um bom padrão de comparação para a intensidade do trabalho é o efeito de
congelamento da interface sobre o fluxo de trabalho do usuário, lembrando
assim o usuário de que a interface existe. Se simplesmente estivermos
movendo arquivos de uma pasta à outra e existir um retardo de dois segundos,
podemos aceitar isso sem problemas. Se encontrar o mesmo retardo de dois
segundos ao compormos uma imagem em um programa de edição de
imagens, talvez isso nos atrapalhe bastante.
Aplicações como Google13, Americanas14, Submarino15, MercadoLivre16, e a
maioria dos aplicativos públicos baseados na Web, são aplicativos transitórios.
Soluções baseadas em páginas Web são suficientemente boas para uso
transitório, mas não para uso soberano.
12
Um depurador, ou debugger, é um programa de computador que é usado para testar outros
programas e fazer sua depuração, isto é, eliminar seus problemas ou bugs.
13
Disponível em http://www.google.com.br/
14
Disponível em http://www.americanas.com.br/
15
Disponível em http://www.submarino.com.br/
16
Disponível em http://www.mercadolivre.com.br/
23
2.6 Desaprendendo a Web
Interatividade complicada, linguagens de criação de scripts e plug-ins foram
estabelecidas à contra gosto nos navegadores Web modernos ao longo dos
anos, em uma corrida para proporcionar a mais atraente experiência
navegacional.
Introduzir uma nova tecnologia é um processo técnico e social. Depois que a
tecnologia está disponível, as pessoas precisam descobrir o que fazer com ela,
e, um primeiro passo costuma ser utilizá-la como se fosse algo mais antigo e
familiar. Essa é a razão porque as bicicletas antigas eram chamadas de
“hobbyhorses” (“cavalinho de pau”) ou “dandy horses” e eram guiadas com os
pés no chão. A medida que a tecnologia foi exposta a um publico mais amplo,
uma segunda onda de inovadores descobriria novas maneiras de utilizar esta
tecnologia, acrescentando melhorias como pedais, freios, engrenagens e
pneus. A cada melhoria incremental a bicicleta se tornava menos parecida com
um cavalo [3].
Os mesmos processos funcionam hoje em dia com o desenvolvimento Web. As
tecnologias por trás do Ajax têm a capacidade de transformar páginas Web em
algo radicalmente novo. Tentativas anteriores de se utilizar as tecnologias Ajax
ainda estavam pressas a noção tradicional de uma página Web e tinham
aquele espírito de “nenhuma coisa nem outra” do hobbyhorse. Para entender o
potencial do Ajax precisamos abandonar o conceito de página Web e, ao fazer
isso, desaprender uma grande quantidade de suposições que fizemos nos
últimos anos.
3 Ajax
O Ajax (Asynchronous JavaScript + XML) é um nome relativamente novo,
cunhado por Jesse James Garrett da Adaptive Path, em seu ensaio “Ajax: A
New Approach to Web Applications”, publicado em 18 de Fevereiro de 2005.
Neste ensaio, o nome Ajax é citado pela primeira vez, onde Garret explica
como ele acredita que as aplicações Web estão estreitando a diferença entre a
elas e as aplicações tradicionais desktop.
24
“Desktop applications have a richness and responsiveness that has seemed out of
reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also
creates a gap between the experiences we can provide and the experiences users can
get from a desktop application.
That gap is closing. Take a look at Google Suggest. Watch the way the suggested
terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use
your cursor to grab the map and scroll around a bit. Again, everything happens almost
instantly, with no waiting for pages to reload.
Google Suggest and Google Maps are two examples of a new approach to web
applications that we at Adaptive Path have been calling Ajax. The name is shorthand for
Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s
possible on the Web.” [4]
Algumas partes do Ajax foram anteriormente descritas como Dynamic HTML e
scripting remoto.
É porem muito mais que um nome. Há muitas expectativas em torno do Ajax e
muito mais a se esperar dele, tanto em uma perspectiva tecnológica como de
negócios. Tecnologicamente o Ajax da vazão a uma grande quantidade de
potenciais não realizados nas tecnologias dos navegadores Web. Google,
Yahoo, Microsoft e alguns outros dos principais competidores estão utilizando o
Ajax para aumentar as expectativas do público em geral sobre o que uma
aplicação Web pode fazer.
3.1 Os quatro princípios definidores do Ajax
O modelo clássico de aplicação baseado em páginas é amarrado em muitas
das estruturas que nós usamos, e também em nossas maneiras de pensar.
Segundo Crane, uma aplicação Ajax deve ser pensada levando em
consideração quatro suposições básicas [3].
3.1.1 O navegador hospeda uma aplicação, não o conteúdo.
Em uma aplicação Web clássica baseada em páginas, o navegador é
efetivamente um terminal burro. Ele não sabe nada sobre onde o usuário está
no fluxo de trabalho maior. Todas essas informações são mantidas no servidor
Web, tipicamente na sessão do usuário. Sessões de usuários no lado servidor
são comuns atualmente. No trabalho com Java ou .NET, a sessão no lado
25
servidor faz parte da API padrão, assim como controle de solicitações,
respostas, e tipos de conteúdo Multipurpose Internet Mail Extensions (MIME). A
Figura 1 ilustra o ciclo de vida típico de uma aplicação Web clássica.
Figura 1
Ciclo de vida típico de uma aplicação Web clássica [3].
Quando o usuário efetua o login17 ou de outra maneira inicia uma sessão,
vários objetos são criados no lado servidor, representando, por exemplo, a
cesta de compras e as credenciais do cliente, se isso for um site de comércio
eletrônico. Ao mesmo tempo, a página inicial é apresentada ao navegador, em
um fluxo de marcação HTML que mistura apresentação de texto padronizado,
dados específicos ao usuário e conteúdo, como uma lista de itens recémvisualizados.
17
Ação necessária para acessar um sistema computacional restrito inserindo uma
identificação.
26
Toda vez que o usuário interage com o site, um outro documento é enviado ao
navegador, contendo a mesma combinação de texto padronizado e dados. O
navegador obedientemente descarta o documento anterior e exibe o novo, uma
vez que ele é burro e não sabe mais o que fazer.
Quando o usuário efetua logout18 ou fecha o navegador, a aplicação fecha e a
sessão é destruída. Qualquer informação que o usuário necessite ver na
próxima vez que ele entrar terá que ser passada para a camada de
persistência de dados em cada visita. Já em uma aplicação Ajax, parte da
lógica da aplicação é movida para o navegador, como a Figura 2 ilustra.
Figura 2
Ciclo de vida de um aplicativo Ajax [3].
Neste novo cenário, quando o usuário efetua login, um documento mais
complexo é entregue ao navegador, uma grande proporção do qual é código
JavaScript. Este documento permanecerá com o usuário por toda a sessão,
18
Ação de sair do sistema
27
embora seja provável que ele mude de aparência consideravelmente enquanto
o usuário está interagindo com ele. O documento sabe como responder às
interações do usuário e é capaz de decidir se deve tratar ele mesmo os dados
inseridos pelo usuário ou passar uma solicitação para o servidor Web (que tem
acesso ao banco de dados do sistema e outros recursos), ou ainda, fazer uma
combinação de ambos.
Como o documento persiste por toda a sessão do usuário, ele pode armazenar
o estado. Por exemplo, o conteúdo de uma cesta de compras pode ser
armazenado no navegador, em vez de ser armazenado na sessão do servidor
[3].
3.1.2 O servidor fornece dados, não conteúdo.
Como observado, uma aplicação Web clássica apresenta a mesma mistura de
texto padronizado, conteúdo e dados em cada passo. Quando nosso usuário
adiciona um item na cesta de compras, tudo que realmente precisamos
responder é o valor atualizado da cesta ou informar se alguma coisa deu
errado. Como ilustrado na Figura 3, isto será uma parte muito pequena do
documento geral.
28
Figura 3
Distribuição do conteúdo entregue (A) por um aplicativo Web clássico e
(B) por um aplicativo Ajax. A medida que o aplicativo continua a ser utilizado, aumenta o
tráfego acumulado (C).
Um carrinho de compras baseado em Ajax pode comportar-se de forma mais
inteligente, enviando solicitações assíncronas ao servidor. O texto padronizado,
o rastro de navegação, e outras características do layout da página já estão
todos carregados, portanto o servidor só precisa enviar os dados relevantes.
Uma aplicação Ajax poderia fazer isto de vários modos, como retornar um
fragmento de JavaScript, um fluxo de texto simples, ou um pequeno documento
XML. Existem as vantagens e desvantagens de cada um, mas é suficiente
dizer que qualquer um destes formatos será relevantemente menor que a
miscelânea devolvida pela aplicação Web clássica.
Em uma aplicação Ajax, a maior parte do tráfego ocorre no início, com um
grande e complexo cliente sendo entregue de uma única vez, quando o usuário
29
efetua o login. Comunicações subseqüentes com o servidor são, porém, muito
mais eficientes. Para um aplicativo transitório, o tráfego acumulado pode ser
menor para uma aplicação Web convencional, mas conforme o tamanho médio
do tempo de interação aumenta, o custo de largura de banda da aplicação Ajax
se torna menor que o da aplicação Web clássica [3].
3.1.3 A interação do usuário com a aplicação pode ser fluente e
contínua
Um navegador Web oferece dois mecanismos de entrada prontos para uso:
hyperlinks e formulários HTML.
Hyperlinks podem ser construídos sobre o servidor e pré-carregados
apontando para páginas dinâmicas ou servlets. Eles podem ser aprimorados
com imagens e Cascading Style Sheets (CSS) para fornecer um feedback
rudimentar, como por exemplo, definir efeitos quando o mouse estiver sobre
eles.
Controles de formulário oferecem um subconjunto básico de componentes
padrões de interface com o usuário: caixas de texto, caixas de checagem e
botões de rádio, além de listas de seleção. Vários possíveis candidatos não
estão presentes. Não existem controles prontos para uso como: estruturas de
árvore, grades editáveis, ou caixas de combinação. Os formulários, assim
como os hyperlinks, apontam para URLs no servidor.
Como alternativa, os hyperlinks e os controles de formulário podem ser
apontados para funções Javascript. É uma técnica comum em páginas Web
fornecer uma validação de formulário rudimentar em Javascript, a fim de
verificar campos vazios, valores fora de intervalo, e assim por diante, antes de
submeter os dados para o servidor. Estas funções Javascript só persistem pelo
tempo da própria página e são substituídas quando a página submete dados ao
servidor.
Enquanto a página está enviando os dados, o usuário aguarda a sua resposta.
A página anterior pode ainda estar parcialmente visível por algum tempo, e o
navegador pode até permitir que o usuário clique em qualquer um dos links
visíveis, mas fazer isto produzirá resultados imprevisíveis e até destruir a
sessão no lado servidor. O usuário está normalmente aguardando a página ser
30
atualizada que, frequentemente, possui quase que as mesmas informações
removidas segundos antes. Afinal de contas, não é provável que a adição de
um par de calças a cesta de compras modifique as categorias de primeiro nível,
de “moda masculina”, “moda feminina”, “infantil” e “acessórios”.
Fixemos no exemplo do carrinho de compras novamente. Como nosso carrinho
de compras Ajax envia dados assincronamente, os usuários podem adicionar
coisas tão rapidamente quanto eles podem clicar. Se o código do carrinho de
compras for robusto, ele tratará esta carga de trabalho facilmente, e os
usuários poderão continuar com o que estão fazendo.
É claro que não existe nenhum carrinho para colocarmos as coisas, somente
um objeto em sessão no servidor. Os usuários não querem saber sobre objetos
de sessão enquanto estão fazendo compras, e a metáfora do carrinho provê
uma descrição do mundo real mais confortável do que está acontecendo.
Alternar contextos entre a metáfora e o acesso direto ao computador é algo
que distrai os usuários. Aguardar uma página ser atualizada levará o usuário à
realidade de estar à frente de um computador por um curto período de tempo, e
nossa implementação em Ajax evita que isto ocorra. Comprar é uma atividade
transitória, mas se considerarmos um domínio de negócios diferente, por
exemplo, um cenário de assistência e atendimento intensivo ou uma tarefa
complexa de engenharia, então o custo de interromper o fluxo de trabalho a
cada poucos segundos com uma atualização de página, é algo inviável.
A segunda vantagem de Ajax é que podemos associar eventos a um amplo
espectro de ações do usuário. Os conceitos mais sofisticados de interface com
o usuário, assim como “arrastar e soltar”, se tornam realizáveis, trazendo as
experiências dessas interfaces em pé de igualdade com os controles de
aplicações desktop. Da perspectiva de usabilidade, esta liberdade não é
importante somente porque ela permite exercitar nossa imaginação, mas
porque ela nos permite combinar a interação do usuário e as solicitações ao
servidor de maneira mais completa.
Para contatar o servidor em uma aplicação Web clássica, precisamos clicar em
um hyperlink ou submeter um formulário, e então esperar. Isso interrompe o
fluxo de trabalho do usuário. Em contraposição, contatar o servidor em
resposta a um movimento ou arraste do mouse, ou um pressionamento de
tecla, permite que o servidor a trabalhe junto com o usuário. O Google
31
Suggest19 é um exemplo muito simples e efetivo disto: responder às teclas
pressionadas enquanto ele digita dentro da caixa de pesquisa, e então,
comunicar com o servidor para recuperar e exibir uma lista de possíveis
finalizações para as expressões, baseada nas pesquisas feitas por outros
usuários do mecanismo de busca em todo o mundo [3].
3.1.4 Uma codificação real requer disciplina
Aplicações Web clássicas fazem uso de JavaScript já há algum tempo para
adicionar penduricalhos as suas páginas. Esta situação desfavorável fez com
que JavaScript recebesse injustamente, uma reputação como um tipo de
linguagem trivial e de baixo nível, não levada em consideração por
desenvolvedores sérios.
Porém isto vem se modificando ao passo que o termo Ajax, e as técnicas
envolvidas, vêm ganhando credibilidade. Codificar uma aplicação Ajax é algo
completamente diferente. O código que você fornece quando os usuários
iniciam a aplicação deve executar até que eles encerrem-na, sem interrupção,
sem diminuição de velocidade, e sem produção de vazamentos de memória.
Se estivermos mirando no mercado de aplicações soberanas, então temos em
vista muitas horas de intenso uso. Para atingirmos este objetivo, devemos
escrever códigos de alto-desempenho, e de fácil manutenção, usando a
mesma disciplina e entendimento que é aplicado com sucesso às camadas do
servidor.
A base de código será tipicamente mais ampla que qualquer código escrito
para uma aplicação Web clássica. Boas práticas na construção da base de
código se tornam muito importantes. O código deve tornar-se responsabilidade
de uma equipe, em vez de uma única pessoa, expondo questões de
manutenção, separações de interesses e estilos e padrões comuns de
codificação.
Uma aplicação Ajax, é, então, um fragmento funcional complexo do código que
se comunica eficientemente com um servidor enquanto o usuário continua com
seu trabalho. Ela é claramente uma descendência da aplicação Web clássica
19
Disponível em: http://www.google.com/webhp?complete=1&hl=em.
32
baseada em páginas, mas a similaridade não é mais forte do que aquela entre
o hobbyhorse anterior e uma moderna bicicleta. Ter em mente estas diferenças
nos ajudará a criar aplicações Web verdadeiramente atraentes [3].
3.2 Ajax no mundo real
O Ajax já é utilizado para a construção de aplicativos reais, e os benefícios da
abordagem Ajax já podem ser vistos.
A Google fez mais do que qualquer outra empresa para aprimorar o perfil dos
aplicativos Ajax. E o Google, como a maioria dos que adotaram esta
tecnologia, estava fazendo isso antes do nome Ajax ser cunhado.
O Google avançou nisso com muitos recursos interativos, como o GMail, um
serviço de e-mail gratuito com uma UI muito leve e responsiva, o Google
Suggest, que pesquisa no servidor possíveis complementos para os termos de
busca à medida que o usuário digita no campo de pesquisa, e o Google Maps,
um mapa ampliável e interativo utilizado para realizar pesquisas baseadas em
localizações.
Ao mesmo tempo outras empresas começaram a experimentar esta tecnologia.
Outra grande utilizadora da tecnologia Ajax é a Yahoo!20, com a página
principal de seu portal em Ajax, com o seu sistema de compartilhamento de
fotos on-line Flickr21, o Yahoo! Maps22, serviço de mapas semelhante ao
Google Maps, entre outros serviços. A Microsoft também vem se tornando um
grande utilizador do Ajax, com seu portal Live.com23, o Windows Live Local24,
outro serviço de mapas, entre outros. Outras aplicações interessantes são os
ditos Desktops Online ou Webtops que são páginas personalizadas, em que é
possível escolher o conteúdo, bem como definir a ordem e a aparência dos
mesmos. Dentre os Webtops mais conhecidos estão o Netvibes25, Protopage26,
iGoogle27, My Yahoo28 e Windows Live29.
20
Disponível em http://br.yahoo.com
21
Disponível em http://www.flickr.com/
22
Disponível em http://maps.yahoo.com/
23
Disponível em http://www.live.com/
24
Disponível em http://local.live.com/
25
Disponível em http://www.netvibes.com/
33
Estes aplicativos até agora estão testando o mercado. Eles continuam sendo
aplicativos transitórios, projetados para uso ocasional. Há sinais de um
mercado emergente para aplicativos Ajax soberanos, com algumas iniciativas
como o Google Docs30, que é um pacote de aplicativos totalmente on-line que
rodam diretamente no navegador Web e que é atualmente composto de um
processador de texto, um editor de apresentações e um editor de planilhas.
Outro sinal importante é a crescente proliferação de frameworks e bibliotecas
para auxiliar o desenvolvimento Ajax, mas isto, veremos mais adiante.
Examinando o estado da arte atual desta tecnologia podemos ter idéia de onde
está a recompensa do uso do Ajax.
3.2.1 Google Maps
O Googgle Maps é um cruzamento entre um visualizador de mapas e um
sistema de pesquisa. Inicialmente o sistema mostra o mapa dos Estados
unidos. O mapa pode ser consultado utilizando texto livre, permitindo afunilar a
pesquisa para endereços de ruas especificas ou até mesmo para nomes de
hotéis e restaurantes.
26
Disponível em http://www.protopage.com/
27
Disponível em http://www.google.com.br/ig
28
Disponível em http://my.yahoo.com/
29
Disponível em http://home.live.com/
30
Disponível em http://documents.google.com/
34
Figura 4
Página inicial do Google Maps.
Clicar em links individuais a partir do resultado da pesquisa fará com que popups31 adicionais sejam exibidas instantaneamente, possivelmente até rolando o
mapa levemente para acomodá-los. A rolagem do mapa é o recurso mais
interessante do Google Maps. O usuário pode arrastar o mapa inteiro usando o
mouse. O mapa é composto por pequenos pedaços, e se o usuário rolar o
mapa até um ponto suficientemente distante para expor um novo pedaço, este
será carregado assincronamente. As vezes há um retardo notável, com uma
área em branco aparecendo inicialmente, que é preenchida depois que o
pedaço do mapa é carregado, entretanto o usuário pode continuar a rolar,
desencadeando solicitações atualizadas daquele pedaço enquanto é feito o
download. Os pedaços do mapa são armazenados em cache pelo navegador
31
O pop-up é uma janela extra que abre no navegador ao visitar uma página web ou acessar
um hiperlink específico.
35
Web até o final da sessão do usuário, tornando muito mais rápido retornar a
uma parte do mapa já visualizada.
Figura 5
Pop-up aberta ao clicar em um item do resultado da pesquisa.
Em questão a usabilidade, duas coisas importantes são visíveis. Primeiro, a
ação que desencadeia o download dos novos dados do mapa não é um link
especifico informando “buscar mais mapas”, mas algo que o usuário está
fazendo de qualquer jeito, isto é, mover o mapa. O fluxo de trabalho do usuário
não é interrompido pela necessidade de se comunicar com o servidor.
Segundo, as próprias solicitações são assíncronas, significando que os links
contextuais, controle de zoom e outros recursos de página continuarão
acessíveis enquanto o mapa coleta novos dados.
Serviços de mapeamento baseados na Internet não são recentes. Se
examinássemos um típico site de mapeamento anterior ao Ajax, veríamos um
conjunto diferente de padrões de interação. Em geral o mapa é dividido em
pedaços. Um controle de zoom e talvez barras de navegação laterais nas
36
margens do mapa poderiam ser fornecidos. Clicar qualquer um destes,
invocaria a atualização da tela inteira, resultando em uma página semelhante a
anterior somente com um pedaço do mapa diferente. O fluxo de trabalho seria
interrompido e, depois de examinar o Google Maps, o usuário descobriria que o
site é lento e frustrante.
Para serviços on-line como o Google, facilidade de uso é um recurso-chave
para que os usuários visitem este serviço e voltem novamente. E o número de
visualização de páginas é uma parte crucial da tomada de decisão para o
negócio. Introduzindo uma UI melhor, com a flexibilidade que o Ajax oferece, o
Google forneceu claramente aos tradicionais serviços de mapeamento algo
com que se preocupar. Certamente há outros fatores, como a qualidade do
serviço de back-end, mas, sendo outras coisas iguais, o Ajax pode fornecer
uma forte vantagem ao negócio.
3.2.2 Google Mail ou GMail
O serviço GMail teve sua versão beta lançada no começo de 2004. Juntamente
com um espaço extremamente generoso de caixa de e-mail32, o principal
comentário sobre o GMail era a UI, que permitia que os usuários visualizarem
todas as mensagens relacionadas com um assunto específico em uma única
janela, de uma maneira escalonada, isso é, fica uma mensagem "acima" da
outra, conforme a ordem cronológica de envio e a atualização da caixa de
entrada
automaticamente,
mesmo
enquanto
o
usuário
digitava
uma
mensagem. Comparando com a média dos sistemas de Web Mail oferecidos
na época, esse foi um passo a frente importante. Comparando com as
interfaces corporativas de Web Mail como o Microsoft Outlook e Lotus Notes, o
GMail oferecia a maioria das funcionalidades sem recorrer a controles ActiveX
incômodos e pesados ou a mini-aplicativos Java, tornando-o disponível para a
maioria das plataformas e localizações, ao invés de somente máquinas
cuidadosamente pré-configuradas de usuários corporativos.
32
O Gmail oferecia, em seu início, 1GB de espaço de armazenamento. O Yahoo! Mail e MSN
Hotmail, que ofereciam 6MB e 2MB, respectivamente, tiveram de rever a questão de espaço
disponível para continuarem tendo condições de concorrerem comercialmente. O mesmo
ocorreu com provedores pagos e gratuitos por todo o mundo.
37
Entre outras características podemos destacar o uso de marcadores, seguindo
a filosofia “pesquise, não classifique”. Basta "colar" um marcador na
mensagem. Este conceito permite uma organização mais elaborada, uma vez
que uma determinada mensagem pode ter vários marcadores. Isso só seria
possível com pastas se mantivéssemos uma cópia da mensagem em cada
pasta. E a mais recente novidade foi à incorporação do serviço de mensagens
instantâneas Google Talk ao Gmail, denominado de Google Chat. Desta forma,
não é necessária nenhum tipo de instalação adicional na máquina do usuário, o
mesmo pode acessar o serviço de mensagens instantâneas diretamente de
dentro do GMail e o Google Chat inclui ainda uma função que salva os
históricos das conversações automaticamente em uma pasta chamada "Chat".
Figura 6
Interface do GMail com apresentação de mensagens de forma
escalonada, mensagens instantâneas e corretor ortográfico.
38
3.2.3 Desktop Online
Um Desktop Online, Webtop, Web Desktop ou OS Online é uma página Web
personalizada, em que é possível escolher o conteúdo, bem como definir a
ordem e a aparência dos mesmos.
São em geral fornecidos por serviços on-line como Google, Yahoo e Windows
Live e normalmente rodam mini-aplicações próprias, mas podem servir de
plataforma também para mini-aplicações desenvolvidas por terceiros.
Um Desktop Online funciona como um Sistema Operacional, porém utilizando
um navegador Web. Alguns deles têm interfaces que lembram desktops de
sistemas operacionais como o Windows e o Linux (KDE) [5].
Alguns dos serviços mais comuns usados nos desktops on-line são:
Canais de notícias RSS, notificador de e-mail, podcasts33, previsão do tempo,
conversor de moedas, calculadora, agenda, gerenciador de arquivos,
gerenciador de favoritos, gerenciador de fotos, pesquisas e alguns contando
com programas de mensagem instantâneas, editores de sites, editores de
blogs e até tocadores de mp3.
33
Podcasting é uma forma de publicação de programas de áudio, vídeo e/ou fotos pela Internet
que permite aos utilizadores acompanhar a sua atualização.
39
Figura 7
Figura 8
Protopage
Goowy
40
Figura 9
Online Operating System
3.2.4 Google Docs
O Google Docs, é um pacote de aplicativos do Google baseado em Ajax.
Funciona totalmente on-line diretamente no navegador Web. Os aplicativos são
compatíveis com o Microsoft Office e o OpenOffice.org, e atualmente compõese de um processador de texto, um editor de apresentações e um editor de
planilhas. Originalmente, o processador de texto foi desenvolvido à parte, sob o
nome Writely, e comprado pelo Google meses depois. Alguns dos recursos
mais peculiares é a portabilidade de documentos, que permite a edição do
mesmo documento por mais de um usuário, bem como o recurso de publicação
direta em blog. Os aplicativos permitem a compilação em PDF.
41
Figura 10
Figura 11
Página Inicial do Google Docs
Planilha do Google Docs.
42
3.3 Alternativas ao Ajax
Podemos esperar que esta tendência aumente à medida que a exposição
publica das interfaces mais ricas se torne mais predominante. Como uma
tecnologia vendável, o futuro do Ajax parece ser brilhante nos próximos anos.
Entretanto outras tecnologias de clientes ricos também estão procurando
ocupar esse espaço.
3.3.1 Adobe Flash, Adobe Flex e Laszlo
Adobe Flash34 é um sistema para execução de animações interativas usando
um formato comprimido de vetores gráficos. Animações em Flash são
interativas e são programadas com ActionScript35, um parente próximo de
Javascript. Suporte para algumas formas de entrada estão disponíveis, e Flash
pode ser usado para qualquer coisa desde jogos interativos até interfaces de
usuário com regras de negócio complexas. Flash tem um suporte muito bom a
vetores gráficos, algo completamente ausente na base das tecnologias de Ajax.
O Flash está presente há muito tempo e é acessado por meio de um plug-in de
navegador. Como uma regra geral, contar com um plug-in de navegador Web é
uma idéia ruim, mas Flash é um plug-in presente na maioria dos navegadores.
Para os propósitos de criação de clientes ricos com Flash, duas tecnologias
muito interessantes são Adobe Flex36 e a suíte livre Laszlo37, ambas provêm
arquiteturas simplificadas no lado servidor, para geração de interfaces de
usuário baseadas em Flash. Ambas as arquiteturas usam Java (J2EE) na
camada do servidor.
34
Disponível em http://www.adobe.com/products/flashplayer/
35
ActionScript é uma linguagem de programação orientada à objetos baseada em ECMAScript,
é executada em uma máquina virtual que está disponível no Flash Player.
36
Disponível em http://www.adobe.com/products/flex/
37
Disponível em http://www.openlaszlo.org/
43
3.3.2 Java Web Start e Microsoft No Touch Deployment
O Java Web Start38 é uma especificação para a distribuição de aplicativos
baseados em Java em um servidor Web de tal maneira que um processo
desktop possa localizar, carregar e executá-los. Estes aplicativos podem ser
acessados através de hyperlinks, permitindo acesso continuo a partir de um
navegador Web cliente do Web Start. O Java Web Start está presente nas
distribuições Java mais recentes, e o processo de instalação ativará
automaticamente o suporte ao Web Start nos navegadores Internet Explorer e
navegadores baseados no Mozilla.
Depois de carregados os aplicativos Web Start são armazenados em uma
sandbox gerenciável no sistema de arquivos e automaticamente atualizados se
uma nova versão for disponibilizada. Isto permite que eles sejam executados
desconectados da rede e reduz o tráfego de rede na recarga, tornando a
implantação de aplicativos pesados, com vários megabytes, uma possibilidade.
Os aplicativos são assinados digitalmente, e o usuário pode optar por fornecer
acesso total ao sistema de arquivos, as portas de rede e a outros recursos.
Tradicionalmente, as UIs do Web Start são escritas em Java Swing, mas existe
o suporte para o Standart Widget Toolkit (SWT).
A plataforma Microsoft .NET oferece um recurso semelhante chamado No
Touch Deployment39, prometendo um mix semelhante de implementação fácil,
UIs ricas e segurança.
A principal desvantagem das duas tecnologias é ter a necessidade de um
programa executável (runtime) pré-instalado. Naturalmente, qualquer cliente
rico precisa de um programa executável, mas o Flash e o Ajax, que utilizam o
próprio navegador Web como programa executável, e os navegadores Web já
se encontram comumente presentes na maioria dos computadores. Na
distribuição atual os programas executáveis Java e .NET estão muito limitados
e não podemos contar com eles para um serviço Web público.
38
Disponível em http://java.sun.com/products/javawebstart/
39
Disponível em http://msdn.microsoft.com/en-us/library/aa289511.aspx
44
3.4 Os elementos-chave do Ajax
O Ajax não é uma tecnologia única. Em vez disso, é uma coleção de quatro
tecnologias que se complementam. A tabela abaixo resume estas tecnologias e
o papel que cada uma tem que desempenhar.
Tabela 1
Os elementos-chave do Ajax
JavaScript
JavaScript é uma linguagem de criação de scripts de uso geral projetada
para ser embutida dentro dos aplicativos. O interpretador JavaScript em
um navegador Web permite interação programática com muitas das
capacidades predefinidas do navegador. Aplicativos Ajax são escritos em
JavaScript.
Cascading Style
CSS oferecem uma maneira de definir estilos visuais reutilizáveis para
Sheets (CSS)
elementos das páginas Web. Eles oferecem uma maneira simples e
poderosa de definir e aplicar estilização visual consistentemente. Em um
aplicativo Ajax, a estilização de uma interface com o usuário pode ser
modificada interativamente por meio de CSS.
Document Object
O DOM apresenta a estrutura das páginas Web como um conjunto de
Model (DOM)
objetos programáveis que pode ser manipulado com JavaScript. Criar
scripts com o DOM permite que um aplicativo Ajax modifique a interface
com o usuário instantaneamente, redesenhando eficazmente parte da
página.
Objeto
O mal nomeado objeto XMLHTTPRequest permite que programadores
XMLHTTPRequest
Web recuperem dados de um servidor Web como uma atividade em
segundo plano. O formato dos dados geralmente é XML, mas funciona
bem com dados baseados em texto. Enquanto o XMLHTTPRequest é a
ferramenta de uso geral mais flexível para este trabalho, há outras
maneiras de recuperar dados do servidor, como técnicas baseadas em
frames.
Um aplicativo Ajax entrega um aplicativo complexo e funcional por demanda
para os usuários, com o qual eles então interagem. O JavaScript é a “cola”
utilizada para montar estes aplicativos, definindo o fluxo de trabalho do usuário
e a lógica de negócio do aplicativo. A interface com o usuário é manipulada e
atualizada utilizando JavaScript para manipular o Document Object Model
(DOM), redesenhando e reorganizando continuamente os dados apresentados
aos usuários e processando suas interações baseadas no mouse e no teclado.
45
As folhas de estilo em cascata (Cascadind Styles Sheets - CSS) fornecem
aparência e comportamento (look and feel) consistentes para o aplicativo e um
atalho poderoso para a manipulação programática do DOM. O objeto
XMLHTTPRequest (ou algum mecanismo semelhante) é utilizado para
conversar com o servidor assincronamente, confirmando as solicitações do
usuário e buscando dados atualizados enquanto o usuário trabalha. A Figura
12 demonstra como as tecnologias se encaixam no Ajax.
Figura 12
Os quatro componentes principais do Ajax [3].
Três das quatro tecnologias – CSS, JavaScript e DOM – têm sido
coletivamente referidas como Dynamic HTML, ou abreviando, DHTML. Por
volta
de
1997,
a
DHTML,
era
a
grande
promessa,
mas,
não
surpreendentemente nessa indústria, nunca conseguiu passar de uma
promessa inicial. A DHTML oferecia a capacidade de criar interfaces interativas
não-convencionais para páginas Web, mesmo assim nunca superou o
problema da atualização da página inteira. Sem voltar para conversar com o
servidor, havia muito pouco a ser feito. O Ajax utiliza maciçamente o DHTML,
mas, acrescentando as solicitações assíncronas, ele pode estender a
46
longevidade de uma página Web consideravelmente. Em razão de voltar ao
servidor enquanto a interface está fazendo seu trabalho, sem interrupção, o
Ajax faz uma grande diferença no resultado final.
Muito convenientemente, todas estas tecnologias já estão pré-instaladas nos
navegadores Web mais modernos, incluindo o Microsoft Internet Explorer, a
família dos navegadores Mozilla/Gecko, incluindo Firefox, Mozilla Suíte,
Netscape Navigator e Camino, o navegador Opera, o Safári da Apple, e seu
primo próximo Konqueror do UNIX KDE. De modo conveniente, as
implementações dessas tecnologias são frustrantemente diferentes em relação
a alguns detalhes e irão variar de uma versão para outra, mas essa situação foi
amenizada nos últimos anos e há maneiras de lidar de um modo claro com as
incompatibilidades de múltiplos navegadores.
Cada sistema operacional moderno vem com um navegador moderno préinstalado. Portanto, a ampla maioria dos computadores desktop e laptop do
planeta já estão preparados para executar aplicativos Ajax.
3.4.1 Orquestrando a experiência do usuário com JavaScript
O papel central do conjunto de ferramentas Ajax é sem duvida desempenhado
pelo JavaScript. Um aplicativo Ajax carrega um cliente completo na memória,
combinando dados, apresentação e a lógica do programa. O JavaScript é a
ferramenta utilizada para implementar essa lógica. O JavaScript é uma
linguagem de programação de uso geral de descendência hibrida, com uma
leve semelhança com a família das linguagens C.
A grosso modo, o JavaScript pode ser caracterizado como uma linguagem de
criação de scripts de uso geral, interpretada e fracamente tipada.
Fracamente
tipada
significa
que
as
variáveis
não
são
declaradas
especificamente como strings, inteiros ou objetos e que é possível atribuir
valores de diferentes tipos a mesma variável.
Interpretada significa que não é compilada no código executável, mas o códigofonte é executado diretamente.
Uso geral significa que a linguagem é adequada para uso com a maioria dos
algoritmos e tarefas de programação. A linguagem JavaScript básica contém
suporte a números, strings, datas e horas, arrays, expressões regulares para
47
processamento de texto e funções matemáticas como trigonometria e geração
de números aleatórios. É possível definir objetos estruturados utilizando
JavaScript, levando os princípios e a ordem de projeto a um código mais
complexo.
Dentro do ambiente do navegador Web, partes da funcionalidade nativa do
navegador, incluindo CSS, DOM e o objeto XMLHHTRequest são expostos ao
mecanismo JavaScript, permitindo que os autores de páginas controlem as
mesmas programaticamente.
Dentro da tecnologia Ajax, o JavaScript é a cola que agrupa todos os outros
componentes. Ter uma familiaridade básica com JavaScript é um pré-requisito
para escrever aplicativos Ajax.
3.4.2 Definindo a aparência e o comportamento com CSS
As folhas de estilo em cascata (Cascading Style Sheets - CSS) são uma parte
bem estabelecida do design Web e são utilizadas tanto em aplicativos Web
clássicos como em aplicativos Ajax. Uma folha de estilo oferece uma maneira
centralizada de definir categorias de estilos visuais, que então podem ser
aplicadas a elementos individuais em uma página de forma concisa. Além dos
elementos óbvios de estilização como cores, bordas, imagens de fundo,
transparência e tamanho, as folhas de estilo podem definir a maneira como os
elementos são organizados em relação um ao outro, e também a sua
interatividade simples com o usuário, permitindo que efeitos visuais bastante
poderosos sejam alcançados somente por meio de folhas de estilo.
Em um aplicativo Web clássico, as folhas de estilo fornecem uma maneira útil
de definir um estilo em um único lugar que pode ser reutilizado em diferentes
páginas Web. Com Ajax, não mais pensamos em termos de uma sucessão
rápida de páginas, mas as folhas de estilo ainda fornecem um repositório útil de
visuais pré-definidos que podem ser aplicados dinamicamente a elementos
com um mínimo de código.
As CSS estilizam um documento definindo regras, normalmente em um arquivo
separado que é referenciado pela página Web sendo estilizada. Regras de
estilo também podem ser definidas dentro da página Web, mas isto geralmente
é considerado uma prática ruim.
48
Uma regra de estilo consiste em duas partes: o seletor e a declaração de
estilo. O seletor especifica quais elementos serão estilizados, e a declaração
de estilo declara quais propriedades de estilo serão aplicadas. Supondo que
queremos que todos os nossos títulos de nível 1 de um documento, isto é, as
tags <H1>, apareçam em vermelho. Devemos declarar uma regra CSS para
fazer isto, como mostra a Listagem 1.
Listagem 1
Exemplo de seletor e declaração de estilo.
H1 {
color: red
}
O seletor aqui é muito simples, e aplica-se a todas as tags <H1> no documento.
A declaração de estilo também é muito simples e modifica uma única
propriedade de estilo. Na pratica tanto o seletor como a declaração de estilo
podem ser consideravelmente mais complexos.
3.4.2.1 Seletores CSS
Além de definir um tipo de tag HTML ao qual aplicar um estilo, podemos limitar
a regra àqueles dentro de um contexto especifico. Há varias maneiras de
especificar o contexto: por tipo de tag HTML, por um tipo de classe declarada
ou por um ID único de elemento.
Primeiro vamos examinar os seletores por tipo de tag. Por exemplo, para
aplicar a regra da listagem anterior apenas as tags <H1> que estão contidas
dentro de uma tag <DIV>, modificaríamos nossa regra como apresentada na
Listagem 2.
Listagem 2
Seletor por tipo de tag HTML.
DIV H1 {
color: red
}
Estes também são conhecidos por seletores baseados em elementos, pois
decidem se um elemento DOM é ou não estilizado com base no seu tipo de
49
elemento. Também podemos definir classes para estilizar isso sem ter nada a
ver com o tipo de tag HTML. Por exemplo, se definirmos uma classe de estilo
chamada caixaazul, que deve aparecer em uma caixa colorida, definiríamos
uma regra como na Listagem 3.
Listagem 3
Seletor por tipo de classe declarada.
.caixazul {
border: solid blue 1px;
background-color: cyan
}
Para atribuir uma classe de estilo a um elemento, simplesmente declaramos
um atributo class na tag HTML, como na Listagem 4.
Listagem 4
Atribuição de classe de estilo.
<div>Eu vou aparecer como um texto normal</div>
<div class="caixaazul">Eu vou aparecer como uma caixa azul</div>
Os elementos podem ser atribuídos a mais de uma classe. Se definíssemos
uma classe de estilo adicional chamada textolaranja, como na Listagem 5.
Listagem 5
Estilo textolaranja.
.textolaranja {
color: orange
}
Podemos aplicar os dois estilos em um documento, como na Listagem 6.
Listagem 6
Elemento com mais de uma classe de estilo.
<div class="textolaranja">Eu sou um texto laranja</div>
<div class="caixaazul">Eu sou um texto em uma caixa colorida</div>
<div class="caixaazul textolaranja"> Eu sou uma mistura dos dois</div>
O terceiro elemento <DIV> aparecerá em texto laranja em uma caixa em ciano
com uma borda azul.
50
Podemos combinar classes com regras baseadas em elementos para definir
uma classe que só opere em tipos de tags específicos. Por exemplo, a
Listagem 7.
Listagem 7
Combinação de classes com regras baseadas em elementos.
span.highlight {
background-color: yellow
}
Esta definição só será aplicada as tags <span> com um atributo de classe
highlight declarada. Outras tags <span> ou outros tipos de elementos com a
class = "highlight" permanecerão inalterados.
Podemos especificar regras que só se aplicam a um elemento com um dado ID
único, especificado pelo atributo id da HTML. Não mais que um elemento em
um documento HTML deve ter um dado ID atribuído a ele, assim, estes
seletores, são em geral utilizados pare selecionar um único elemento em uma
página. Por exemplo, para atrair a atenção para um botão “Fechar” em uma
página, podemos criar um estilo como o da Listagem 8.
Listagem 8
Seletor por ID único de elemento.
#botaovermelho {
color: red
}
As folhas de estilo também permitem definir estilos com base em pseudoseletores. Alguns pseudo-seletores úteis incluem first-letter, que altera o
comportamento da primeira letra de um elemento, first-line, que altera a
primeira linha de um elemento e hover, que nos permite modificar a aparência
dos hiperlinks quando o ponteiro do mouse passa sobre eles. Por exemplo,
para alterarmos a cor de um link para amarelo quando o ponteiro do mouse
passar sobre ele, podemos definir uma regra como a da Listagem 9.
Listagem 9
Pseudo-seletores.
a:hover {
color: yellow
51
}
3.4.2.2 Propriedades de estilo CSS
Cada elemento em uma página HTML pode ser estilizado de diferentes
maneiras. O texto de um elemento pode ser estilizado em termos de cores,
tamanho de fonte, corpo da fonte e a família da fonte a se utilizar. Múltiplas
opções podem ser especificadas para fontes, a fim de permitir uma degradação
elegante nas situações onde uma fonte desejada não esteja instalada na
máquina do cliente. Por exemplo, a Listagem 10 mostra uma regra para
estilizar um parágrafo com texto de cor cinza, em negrito e fonte Courier New.
Listagem 10
Exemplo de propriedades para estilização de fontes.
.textocinza {
font-size: 14pt;
font-family: courier new, courier, monospace;
font-weight: bold;
folor: gray;
}
As folhas de estilo podem definir o layout e o tamanho de um elemento,
especificando as margens e os elementos de preenchimento, tanto para todos
os quatro lados como para cada um individualmente, como na Listagem 11.
Listagem 11
Exemplo de propriedades para estilização de layout
.paddedtodos {
padding: 4 px;
}
.paddedindividual {
padding-botton: 8px;
padding-top: 2px;
padding-left: 4px;
padding-right: 16px;
margin: 1px;
}
52
As dimensões de um elemento podem ser especificadas pelas propriedades de
largura (width) e altura (height). A posição de um elemento pode ser
especificada como absoluta ou relativa. Elementos posicionados de maneira
absoluta podem ser posicionados na página configurando as propriedades top
e left, enquanto elementos posicionados de uma maneira relativa fluirão com
o restante da página.
As cores de fundo podem ser configuradas utilizando a propriedade
background-color. Além disso, uma imagem de fundo pode ser configurada
utilizando a propriedade background-image, como na Listagem 12.
Listagem 12
Propriedade background-image.
.barratitulo {
background-image: url(imagens/topbar.png);
}
Os
elementos
podem
permanecer
ocultos
da
visão
configurando
visibility:hidden ou display:none. No primeiro caso, o item ainda
ocupará espaço na página, se posicionando relativamente, enquanto no último
caso, ele não ocupará.
3.4.3 Organizando a interface usando DOM
O Document Object Model (DOM) expõe um documento (uma página Web) ao
mecanismo JavaScript. Usando o DOM a estrutura de um documento pode ser
manipulada programaticamente. Esta é uma habilidade particularmente útil
para se ter à disposição ao escrever uma aplicação Ajax. Em uma aplicação
Web clássica, atualizamos regularmente a página inteira com novos fluxos de
HTML a partir do servidor e podemos redefinir boa parte da interface através da
apresentação de novo código HTML. Em uma aplicação Ajax, a maioria das
alterações na interface do usuário será feita usando o DOM.
Os elementos HTML em uma página Web estão organizados em uma estrutura
em forma de árvore. A raiz desta árvore é a tag <HTML>, que representa o
documento. Dentro dela temos a tag <BODY>, a qual representa o corpo do
documento, ela é a raiz da estrutura do documento visível. Dentro do corpo,
53
encontramos tags de tabelas, parágrafos, listas, e outros tipos de tags,
possivelmente com outras tags dentro delas.
Uma representação de uma página Web, através do DOM, é também
estruturada como uma árvore, composta de elementos ou nós, que podem
conter nós filhos dentro deles, e assim por diante recursivamente. O
mecanismo JavaScript expõe o nó raiz da página Web atual através da variável
global document, que serve como ponto de partida para todas as nossas
manipulações DOM. O elemento DOM está bem definido pela especificação da
W3C. Ele tem um único elemento pai, zero ou mais elementos filhos, e
qualquer número de atributos que são armazenados como um array associativo
(isto é, por uma chave textual, como width ou style, em vez de um índice
numérico). A Figura 13 representa a estrutura de uma página Web qualquer,
vista utilizando a ferramenta Mozilla DOM Inspector.
Figura 13
O DOM representa um documento HTML em forma de arvore.
54
O relacionamento é de duas vias. Modificar o DOM irá alterar a marcação
HTML e, consequentemente, a apresentação da página.
3.4.3.1 Trabalhando com DOM utilizando JavaScript
Com o DOM podemos adicionar qualquer elemento em uma página, definindo
seu conteúdo e os seus atributos. Assim, podemos colocar novos parágrafos,
itens em listas, e até mesmo criar uma página inteira somente utilizando o
DOM.
3.4.3.1.1 Localizando um nó DOM
A primeira coisa que precisamos fazer a fim de trabalhar em um nó DOM com
JavaScript é localizar os elementos que queremos alterar. Como mencionado
anteriormente, tudo o que temos de inicio é uma referencia ao nó raiz, na
variável global document. Cada nó no DOM é filho (ou neto, bisneto, e assim
por diante) de document, mas pesquisar a árvore mais a fundo, passo a passo,
poderia ser um processo árduo em um documento grande e complexo.
Felizmente, existem alguns atalhos. O mais comumente utilizado é sinalizar um
elemento com um ID único. Podemos ver um exemplo na Listagem 13, onde
atribuímos um ID de nome divVazio a um elemento do tipo DIV.
Listagem 13
Atribuição de ID a um elemento DOM.
<div id="divVazio"></div>
Qualquer nó DOM pode ter um ID atribuído a ele e o ID pode então ser
utilizado para obter uma referencia programática aquele nó em uma chamada
de função, onde quer que ele esteja no documento. Podemos obter esta
referência
ao
elemento
através
do
método
do
objeto
Document
getElementById(), como na Listagem 14.
Listagem 14
O método getElementById().
var hello = document.getElementById("hello");
Em algumas situações, queremos percorrer a árvore DOM passo a passo.
Como os nós DOM são organizados em forma de árvore, cada nó DOM não
55
possuirá mais que um pai, mas qualquer número de filhos. Estes podem ser
acessados pelas propriedades parentNode e childNodes. A propriedade
parentNode retorna um outro objeto do nó DOM, enquanto childNodes
retorna um array JavaScript dos nós, que podem ser interados, como mostra a
Listagem 15.
Listagem 15
A propriedade childNodes.
var filhos = divVazio.childNodes;
for (var i = 0; i < filhos.length; i++) {
…
}
Nós DOM também podem ser procurados com base nos seus tipos de tags
HTML,
utilizando
getElementsByTagName().
Por
exemplo,
document.getElementsByTagName("UL") retornará um array de todas as tags
<UL> do documento.
Esses métodos são úteis para trabalhar com documentos sobre os quais temos
relativamente pouco controle. Como regra geral, é mais seguro utilizar
getElementById() que getElementsByTagName(), uma vez que este faz
menos suposições sobre a estrutura e o ordenamento do documento, o que
pode mudar independentemente do código.
3.4.3.1.2 Criando um nó DOM
Além de reorganizar os nós DOM existentes, há casos em que queremos criar
nós totalmente novos e adicioná-los ao documento. As implementações
JavaScript do DOM também fornecem métodos para fazer isto.
O método createElement() do objeto Document pode ser utilizado para criar
qualquer elemento HTML, aceitando um tipo de tag como argumento, como
mostra a Listagem 16.
Listagem 16
O método createElement().
var elementoFilho = document.createElement("div");
56
O método createTextNode() cria um nó DOM que representa uma parte do
texto, comumente aninhado dentro do cabeçalho, div, parágrafo, e tags de itens
de lista, como mostra a Listagem 17.
Listagem 17
O método createTextnode().
var nodoTexto = document.createTextNode("Algum texto... ");
O DOM padrão trata os nós de texto separadamente daqueles que
representam elementos HTML. Eles não podem ter estilos aplicados a eles
diretamente e, como conseqüência, consomem bem menos memória. O texto
representado por um nó de texto, porém, pode ser estilizado pelo elemento
DOM que o contém.
Depois de o nó, de qualquer que seja o tipo, ter sido criado, ele precisa ser
anexado ao documento para que seja visível no navegador Web. O método
appendChild() do nó DOM é utilizado para realizar isto, como visto na
Listagem 18.
Listagem 18
O método appendChild().
document.getElementById("divVazio").appendChild(elementoFilho);
3.4.3.1.3 Adicionando estilos ao documento
As CSS oferecem uma maneira concisa de aplicar estilos predefinidos e
reutilizáveis aos documentos. Também podemos estilizar os elementos que
criamos no código tirando proveito das CSS.
A propriedade className de um nó DOM nos permite estilizar um elemento
através com as regras definidas em uma classe de estilo declarada, como na
Listagem 19.
Listagem 19
A propriedade className.
document.getElementById("divVazio").className="textolaranja";
Isto fornece uma maneira fácil e compacta de atribuir muitas regras CSS de
uma só vez em um nó e gerenciar estilizações complexas por meio de folhas
57
de estilo. Em outras situações talvez seja necessário fazer uma alteração mais
refinada no estilo de um elemento em particular, possivelmente suplementando
os estilos já aplicados por meio de CSS.
Nós DOM também contêm um array associativo chamado style que contêm
todos os detalhes do estilo do nó. Atribuir um className ao nó modificará os
valores do array style. O array style pode ser manipulado diretamente, como
pode ser visto na Listagem 20.
Listagem 20
A propriedade style.
document.getElementById("divVazio").style.border="solid Green 2px";
document.getElementById("divVazio").style.width="200px";
3.4.3.1.4 Utilizando a propriedade InnerHTML
Os métodos descritos anteriormente fornecem controle de baixo nível a API
DOM. Mas creteElement() e appendChild() fornecem uma API prolixa para
construir um documento e são mais adequadas para situações onde o
documento a ser criado segue uma estrutura regular que pode ser codificada
como um algoritmo. Elementos DOM de todos os navegadores Web populares
também suportam uma propriedade chamada innerHTML, que permite que
conteúdo arbitrário seja adicionado a um elemento de uma maneira muito
simples.
A propriedade innerHTML é uma string que representa os filhos de um nó como
marcação HTML. Por exemplo, na Listagem 21, adicionamos um elemento DIV
com um texto dentro de outro elemento DIV sem precisarmos utilizar funções
como createElement() e addChild().
Listagem 21
A propriedade innerHTML.
document.getElementById("divVazio").innerHTML=
"<div class='caixazul'> Algum texto… </div>";
3.4.4 Carregando dados assincronamente
Ao trabalhar em um aplicativo, especialmente um soberano, os usuários
estarão interagindo continuamente com o aplicativo como parte do fluxo de
58
trabalho. Já discutimos a importância de manter a aplicação responsiva. Se
toda a aplicação pára enquanto uma tarefa secundária prolongada é
executada, o usuário é interrompido. Discutimos as vantagens da chamada de
métodos assíncronas como uma maneira de melhorar a agilidade de resposta
da interface do usuário ao executar tarefas prolongadas, e notamos que,
devido à latência da rede, todas as chamadas ao servidor devem ser
consideradas como demoradas. E observamos também, que sob o modelo
básico HTTP de solicitação-resposta, isto era quase inviável. Aplicações Web
clássicas baseiam-se em recarregamentos de página inteira a cada chamada
ao servidor levando a freqüentes interrupções para o usuário.
Embora tenhamos que aceitar que uma solicitação de um documento
permanece bloqueada até que o servidor retorne sua resposta, temos algumas
formas de fazer uma solicitação ao servidor parecer assíncrona para os
usuários, permitindo que eles continuem trabalhando. As primeiras tentativas
em prover esta comunicação em segundo plano utilizavam IFrames. Mais
recentemente, o objeto XMLHttpRequest forneceu uma solução mais poderosa
e mais transparente.
3.4.4.1 IFrames
Quando DHTML chegou nas versões 4 do Netscape Navigator e do Microsoft
Internet Explorer, ele introduziu um layout flexível e programável para a página
Web. Uma extensão natural do antigo Frameset do HTML foi o IFrame. O I é
abreviatura de inline, o que significa que o frame é parte do layout de um outro
documento, em vez de se posicionar lado a lado como em um Frameset. Um
IFrame é representado como um elemento na árvore DOM, o que significa que
podermos movê-lo, redimensioná-lo, e até mesmo ocultá-lo completamente
enquanto a página está visível. A inovação fundamental veio quando as
pessoas começaram a perceber que um IFrame poderia ser estilizado para que
seja completamente invisível. Isto permitiu carregar dados em segundo plano,
enquanto
a
experiência
visível
do
usuário
permanecia
inalterada.
Repentinamente, havia um mecanismo para se comunicar com o servidor
assincronamente, embora baseado em uma manipulação de código bastante
exótica. A Figura 14 ilustra a seqüência de eventos por trás desta abordagem.
59
Figura 14
Seqüência de eventos em uma comunicação assíncrona [3].
Assim como ocorre com outros elementos DOM, um IFrame pode ser
declarado em HTML para uma página ou ser programaticamente criado
utilizando document.createElement(). Em um simples caso, no qual
queremos que somente um único IFrame não-visível carregue os dados,
podemos declará-lo como parte do documento e obter uma referência de forma
programática utilizando document.getElementById().
3.4.4.2 Objetos XMLDocument e XMLHttpRequest
Os IFrames podem ser utilizados para solicitar dados nos bastidores, mas é
essencialmente um hack, uma manipulação imprevista do código, dando um
novo propósito para algo originalmente introduzido para exibição de conteúdo
visível dentro de uma página. Versões posteriores dos navegadores Web
populares introduziram objetos apropriados destinados a transferência
assíncrona de dados, os quais, oferecem algumas vantagens convenientes
sobre os IFrames.
Os objetos XmlDocument e XMLHttpRequest são extensões não padronizadas
no DOM dos navegadores Web, que acabaram sendo suportados pela maioria
dos navegadores. Eles simplificam consideravelmente o processo de efetuar
chamadas assíncronas, pois são explicitamente projetados para recuperar
dados em segundo plano. Ambos os objetos se originaram como componentes
60
ActiveX40 específicos da Microsoft, que estavam disponíveis como objetos
JavaScript no navegador Internet Explorer. Desde então, outros navegadores
implementaram objetos nativos com funcionalidade e API semelhantes. Ambos
executam funções similares, mas o XMLHttpRequest provê um controle mais
detalhado sobre a solicitação, sendo este o mais utilizado na implementação de
mecanismos Ajax.
A
Listagem
22
mostra
uma
função
simples
que
cria
um
objeto
XMLHttpRequest.
Listagem 22
Exemplo de função de criação do objeto XMLHttpRequest.
function getXMLHTTPRequest() {
var xRequest = null;
if (window.XMLHttpRequest) {
xRequest = new XMLHttpRequest(); // Mozilla/Safari
} else if (typeof ActiveXObject != "undefined") {
xRequest = new ActiveXObject("Microsoft.XMLHTTP"); // IE
}
return xRequest;
}
Essa função retornará um objeto XMLHttpRequest com uma API idêntica na
maioria dos navegadores modernos. A maneira de criar o objeto difere
consideravelmente.
O código verifica o suporte ao objeto XMLHttpRequest nativo (que ele
localizará nos navegadores Mozilla e Safári recentes), se não houver, ele irá
recorrer ao objeto ActiveX, testando se ele é ou não suportado (o que será
verdade apenas nos navegadores da Microsoft). Em um navegador que não
suporta nenhum deles, retornará o valor null. Portanto, é possível criar um
objeto que enviará solicitações ao servidor automaticamente.
3.4.4.3 Enviando uma solicitação para o servidor
Enviar uma solicitação ao servidor a partir de um objeto XMLHttpRequest é
bem simples e direta. Tudo o que precisamos fazer é fornecer a URL das
40
ActiveX é uma tecnologia da Microsoft para o desenvolvimento de páginas dinâmicas.
61
páginas do servidor que irão gerar os dados. A Listagem 23 mostra um
exemplo de como isto é feito.
Listagem 23
Exemplo de envio de solicitação através do objeto XMLHttpRequest.
function sendRequest(url, parametros, metodoHttp) {
if (!metodoHttp) {
metodoHttp = "POST";
}
var req = getXMLHTTPRequest();
if (req) {
req.onreadystatechange = onReadyState;
req.open(metodoHttp, url, true);
req.setRequestHeader("Content-Type",
"application/x-www-form-
urlencoded");
req.send(parametros);
}
}
O método sendRequest() é construído de maneira que o segundo e terceiro
parâmetro são opcionais, assumindo por padrão o uso de POST caso não seja
informado o método HTTP como parâmetro.
O código nessa listagem configura a solicitação e retornará o controle
imediatamente, enquanto a rede e o servidor esperam. Isso é bom para a
responsividade, mas como saber que a solicitação foi completada?
3.4.4.4 Usando funções de retorno de chamada
A segunda parte da equação para tratar comunicações assíncronas é
configurar um ponto de reentrada no código, a fim de receber os resultados da
chamada depois de concluída. Isso geralmente é implementado atribuindo uma
função de retorno de chamada, isto é, um trecho de código que será invocado
quando os resultados estiverem prontos, em algum ponto não especificado no
futuro.
Funções de retorno de chamada se ajustam a abordagem de programação
baseada em eventos, utilizadas nos conjuntos de ferramentas mais modernos
de UI, pressionamentos de teclado, cliques do mouse e alguns outros também
ocorrerão em pontos não especificados no futuro, e o programador antecipa
62
estes eventos escrevendo uma função para tratá-los quando eles ocorrem. Ao
codificar eventos de UI em JavaScript, atribuímos funções para onkeypress,
onmouseover e outras propriedades com nomes semelhantes de um objeto. Ao
codificar retornos de chamada e uma solicitação de servidor, encontramos
propriedades semelhantes chamadas onload e onreadystatechange.
Tanto o Internet Explorer como o Mozilla suportam o retorno de chamada
onreadystatechange. Uma simples rotina de retorno de chamada é
demonstrada na Listagem 24.
Listagem 24
Exemplo de rotina de retorno de chamada.
var req = null;
var console = null;
var READY_STATE_UNINITIALIZED = 0;
var READY_STATE_LOADING = 1;
var READY_STATE_LOADED = 2;
var READY_STATE_INTERACTIVE = 3;
var READY_STATE_COMPLETE = 4;
function sendRequest(url, parametros, metodoHttp) {
if (!metodoHttp) {
metodoHttp = "GET";
}
req = getXMLHTTPRequest();
if (req) {
req.onreadystatechange = onReadyState;
req.open(metodoHttp, url, true);
req.setRequestHeader("Content-Type",
"application/x-www-form-
urlencoded");
req.send(parametros);
}
}
function onReadyState() {
var ready = req.readyState;
var dados = null;
if (ready == READY_STATE_COMPLETE) {
dados = req.responseText;
} else {
dados = "carregando… [" + ready + "]";
63
}
// Faz algo com os dados
}
Primeiro alteramos a função sendRequest() para informar ao objeto da
solicitação qual é a sua rotina de tratamento de retorno de chamada, antes de
enviá-lo. Segundo, defini-se a função de tratamento que na listagem foi
chamada onReadyState().
A propriedade readyState pode aceitar um intervalo de valores numéricos. Na
listagem foram atribuídas variáveis identificadas descritivamente para cada um
destes valores numéricos. O código da listagem só está interessado em
verificar o valor 4, correspondente a conclusão da solicitação.
3.4.5 Ciclo de vida completo
Agora há informação suficiente para agrupar o ciclo de vida completo da carga
de um documento. Instanciamos o objeto XMLHttpRequest, instruindo-o a
carregar um documento e então monitoramos o processo de carregamento
assincronamente utilizando rotinas de tratamento de retorno de chamada.
Nesse exemplo simples da Listagem 25, definimos um nó DOM chamado
console, para o qual geramos informações sobre status para obter um registro
escrito do processo de carregamento.
Listagem 25
Exemplo de ciclo de vida completo de carga de um documento.
<html>
<head>
<script type="text/javascript">
var req = null;
var console = null;
var READY_STATE_UNINITIALIZED = 0;
var READY_STATE_LOADING = 1;
var READY_STATE_LOADED = 2;
var READY_STATE_INTERACTIVE = 3;
var READY_STATE_COMPLETE = 4;
function sendRequest(url, parametros, metodoHttp) {
64
if (!metodoHttp) {
metodoHttp = "GET";
}
req = getXMLHTTPRequest();
if (req) {
req.onreadystatechange = onReadyState;
req.open(metodoHttp, url, true);
req.setRequestHeader("Content-Type",
"application/x-www-form-
urlencoded");
req.send(parametros);
}
}
function getXMLHTTPRequest() {
var xRequest = null;
if (window.XMLHttpRequest) {
xRequest = new XMLHttpRequest(); // Mozilla/Safari
} else if (typeof ActiveXObject != "undefined") {
xRequest = new ActiveXObject("Microsoft.XMLHTTP"); // IE
}
return xRequest;
}
function onReadyState() {
var ready = req.readyState;
var dados = null;
if (ready == READY_STATE_COMPLETE) {
dados = req.responseText;
} else {
dados = "carregando… [" + ready + "]";
}
toConsole(dados);
}
function toConsole(dados) {
if (console != null) {
var novaLinha = document.createElement("div");
console.appendChild(novaLinha);
var texto = document.createTextNode(dados);
novaLinha.appendChild(texto);
}
65
}
window.onload = function() {
console = document.getElementById("console");
sendRequest("dados.txt");
}
</script>
</head>
<body>
<div id="console"></div>
</body>
</html>
Figura 15
Figura 16
Neste
Resultado da execução da solicitação visualizado no Internet Explorer.
Resultado da execução da solicitação visualizado no Mozilla Firefox.
exemplo foi utilizada
a
propriedade
responseText
do
objeto
XMLHttpRequest para recuperar a resposta como uma string de texto. Isto é
66
útil para dados simples, mas se precisarmos que uma coleção estruturada
maior dos dados seja retornada, então se pode utilizar a propriedade
responseXML. Se tiver sido alocado o tipo MIME text/xml a resposta, então
teremos um documento DOM como resposta, o qual podemos acessar
programaticamente seus atributos e funções como getElementById() e
childNodes.
Como exemplo de resposta no formato XML podemos modificar o código da
Listagem 25. O arquivo de resposta será um documento XML bem simples, que
chamaremos de dados.xml, como na Listagem 26.
Listagem 26
Arquivo XML retornado como resposta no exemplo
<?xml version="1.0" ?>
<root>
Texto de teste da requisicao!
</root>
Modificaremos o método onReadyState para receber uma resposta XML,
através da propriedade responseXML como na Listagem 27.
Listagem 27
Método onReadyState modificado para receber uma resposta em XML
function onReadyState() {
var ready = req.readyState;
var dados = null;
if (ready == READY_STATE_COMPLETE) {
dados = req.responseXML;
toConsole(dados);
}
}
Também alteramos o método toConsole para tratar a resposta agora em XML.
Como vemos na Listagem 28.
Listagem 28
Método toConsole modificado para receber uma resposta em XML
function toConsole(dadosXML) {
if (console != null) {
var novaLinha = document.createElement("div");
67
console.appendChild(novaLinha);
var rootNode = dadosXML.getElementsByTagName("root").item(0);
var texto = document.createTextNode(rootNode.firstChild.data);
novaLinha.appendChild(texto);
}
}
E por fim nosso pedido de requisição ao servidor, pedindo o arquivo
dados.xml, como vemos na Listagem 29.
Listagem 29
Requisição pedindo um arquivo XML
window.onload = function() {
console = document.getElementById("console");
sendRequest("dados.xml");
}
Estes são, então, os blocos de construção do Ajax. Cada um trás algo útil, mas
uma boa parte do poder do Ajax é proveniente da maneira como as partes são
combinadas em um todo.
3.5 JSON
JSON é um outro formato para intercambio de dados, e é visto como uma
alternativa ao XML em aplicações Ajax. Grandes empresas como Google e
Yahoo! adotaram JSON como formato de intercambio de dados em diversas de
suas aplicações.
3.5.1 O Objeto Literal JavaScript
A especificação do ECMA Script (ECMA262, 3rd Edition, December 1999), que
formaliza o JavaScript, define na página 2 (4.2) a sentença:
“An ECMAScript object is an unordered collection of properties each with
zero or more attributes…” [6]
68
Essa definição é o que se chama de objeto literal, que é uma coleção não
ordenada de propriedades com um ou mais elementos, onde esses elementos
podem ser valores primitivos comuns a todas as linguagens como: inteiro,
string ou char; ou outros objetos. A Listagem 30 demonstra um objeto literal
JavaScript.
Listagem 30
Exemplo de objeto literal JavaScript
var produto = {
nome:"Celular Nokia N95",
valor:1999,
frete:50,
getValorTotal:function() {
return (this.valor + this.frete)
}
}
3.5.2 O que é JSON
Douglas Crockford, propôs um formato de troca de dados simples com base no
objeto literal do JavaScript, que denominou de JSON (JavaScript Object
Notation).
“JSON é uma formatação leve de troca de dados. Para seres humanos,
é fácil de ler e escrever. Para máquinas, é fácil de interpretar e gerar.
Está baseado em um subconjunto da linguagem de programação
JavaScript, Standard ECMA-262 (3a Edição - Dezembro - 1999). JSON
é em formato texto e completamente independente de linguagem, pois
usa convenções que são familiares às linguagens C e familiares,
incluindo C++, C#, Java, JavaScript, Perl, Python e muitas outras. Estas
propriedades fazem com que JSON seja um formato ideal de troca de
dados.” [7]
JSON está constituído em duas estruturas:
69

Uma coleção de pares nome/valor. Em várias linguagens, isto é
caracterizado como um object, record, struct, dicionário, hash table,
keyed list, ou arrays associativas.

Uma lista ordenada de valores. Na maioria das linguagens, isto é
caracterizado como uma array, vetor, lista ou sequência.
Estas são estruturas de dados universais. Virtualmente todas as linguagens de
programação modernas as suportam, de uma forma ou de outra. É aceitável
que um formato de troca de dados que seja independente de linguagem de
programação se baseie nestas estruturas.
Em JSON, os dados são apresentados da seguinte forma:
3.5.2.1 Objeto
Um objeto é um conjunto desordenado de pares nome/valor. Um objeto
começa com { (chave de abertura) e termina com } (chave de fechamento).
Cada nome é seguido por : (dois pontos) e os pares nome/valor são seguidos
por , (vírgula). A Figura 17 ilustra a estrutura de um objeto no formato JSON.
Figura 17
Objeto em notação JSON
A Listagem 31 demonstra um exemplo de objeto no formato JSON.
Listagem 31
Exemplo de um objeto em notação JSON
var contato = {
nome:"Ulysses Kuntze",
email:"[email protected]",
aniversário:"30/10/1981"
}
70
3.5.2.2 Array
Um array é uma coleção de valores ordenados. O array começa com [
(colchete de abertura) e termina com ] (colchete de fechamento). Os valores
são separados por , (vírgula). A Figura 18 ilustra a estrutura de um array no
formato JSON.
Figura 18
Array em notação JSON
A Listagem 32 demonstra um exemplo de array no formato JSON.
Listagem 32
Exemplo de um array em notação JSON
var contato = {
nome:"Ulysses Kuntze",
email:"[email protected]",
aniversário:"30/10/1981",
telefones:[
'84028077',
'32487738'
]
}
3.5.2.3 Valor
Um valor pode ser uma cadeia de caracteres (string), ou um número, ou true
ou false, ou null, ou um objeto ou um array. Estas estruturas podem estar
aninhadas. A Figura 19 ilustra a estrutura de um valor no formato JSON.
71
Figura 19
Valor em notação JSON
A Listagem 33 demonstra um exemplo de valores e estruturas aninhadas no
formato JSON.
Listagem 33
Exemplo de valores e estruturas aninhadas em notação JSON
var contato = {
nome:"Ulysses Kuntze",
email:"[email protected]",
aniversário:"30/10/1981",
telefones:[
'84028077',
'32487738'
],
endereco:{
rua:"Irmã Bonavita",
numero:11,
mapa:{
latitude:12.123456,
longitude:65.654321
}
}
}
72
3.5.2.4 String
Uma string é uma coleção de nenhum ou mais caracteres Unicode, envolvido
entre aspas duplas usando barras invertidas como caractere de escape. Um
caractere está representando como um simples caractere de string. Uma
cadeia de caracteres é parecida com uma cadeia de caracteres em C ou Java.
A Figura 20 ilustra a estrutura de uma string no formato JSON.
Figura 20
String em notação JSON
A Listagem 34 demonstra um exemplo de string no formato JSON.
Listagem 34
Exemplo de string em notação JSON
var teste = {
string:"Texto de \"teste\" meramente ilustrativo"
}
73
3.5.2.5 Número
Um número é similar a um número em C ou Java, exceto pelo fato de não se
usar os números octais e hexadecimais. A Figura 21 ilustra a estrutura de um
número no formato JSON.
Figura 21
Número em notação JSON
Espaços em branco podem ser inseridos em qualquer parte dos símbolos.
Exceto por pequenos detalhes, a linguagem foi completamente descrita acima.
3.5.3 Parsers JSON
Existem códigos de processamento JSON prontos em dezenas de linguagens,
praticamente em todas as linguagens modernas. A lista de linguagens
suportadas incluem ActionScript, C/C++, C#, Delphi, ColdFusion, Java,
JavaScript, Objective CAML, Perl, PHP, Python, Rebol, Ruby, e Lua. Uma lista
completa pode ser encontrada no site do projeto ( http://www.json.org ).
Em JavaScript o parser para JSON é extremamente simples, e consiste apenas
em chamar a função eval() que é nativa da especificação da linguagem.
Como exemplo iremos alterar novamente o código apresentado na Listagem
25. O arquivo de resposta será um documento texto bem simples, que
chamaremos de json.txt, este arquivo possui uma string em formato JSON,
como na Listagem 35.
74
Listagem 35
Conteúdo do arquivo json.txt
{[
{nome:"UFSC", endereco:"http://www.ufsc.br" },
{nome:"CTC", endereco:"http://www.ctc.ufsc.br/" },
{nome:"INE", endereco:"http://www.inf.ufsc.br/" }
]}
Modificaremos o método onReadyState para receber uma resposta de texto
em notação JSON, através da propriedade responseText, e então passamos
esta resposta ao método eval() que fará o parser da notação JSON para um
objeto literal JavaScript, como na Listagem 36.
Listagem 36
Método onReadyState modificado para receber uma resposta JSON
function onReadyState() {
var ready = req.readyState;
var dadosJSON = null;
if (ready == READY_STATE_COMPLETE) {
dadosJSON = eval(req.responseText);
toConsole(dadosJSON);
}
}
Também alteramos o método toConsole para tratar a resposta agora em
JSON. Como vemos na Listagem 37.
Listagem 37
Método toConsole modificado para receber um parâmetro JSON
function toConsole(dadosJSON) {
if (console != null) {
for (var i=0; i<dadosJSON.length; i++) {
var novaLinha = document.createElement("div");
console.appendChild(novaLinha);
//recupera o nome
var nome = dadosJSON[i].nome;
//recupera o endereco
var endereco = dadosJSON[i].endereco;
var texto = document.createTextNode(nome + ' - ' + endereco);
novaLinha.appendChild(texto);
}
75
}
}
E por fim nosso pedido de requisição ao servidor, pedindo o arquivo json.txt
que contém uma string em formato JSON. Como vemos na Listagem 38.
Listagem 38
Requisição de resposta em formato JSON
window.onload = function() {
console = document.getElementById("console");
sendRequest("json.txt");
}
3.5.4 JSON vs XML
Normalmente o retorno das requisições Ajax é tratado como XML. Isso implica
que o código JavaScript deverá percorrer toda a estrutura do XML e interpretálo.
Existem duas grandes vantagens na utilização de JSON. A primeira delas é a
redução da quantidade de dados que retornam do servidor. A descrição de um
objeto em JSON é bem mais enxuta que a descrição do mesmo objeto em
XML. As Listagens 39 e 40 demonstram a diferença entre o formato XML e
JSON na descrição de um produto.
Listagem 39
Exemplo em formato XML
<produtos>
<produto id="1">
<nome>Refrigerante da Maroca</nome>
<fornecedor>Maroca Ltda.</fornecedor>
<contato>Mara Regina</contato>
<telefone>011-1111-1111</telefone>
</produto>
</produtos>
Listagem 40
Exemplo em formato JSON
[{
id:1,
76
nome:'Refrigerante da Maroca',
fornecedor:'Maroca Ltda.',
contato:'Mara regina',
telefone:'011-1111-1111'
}]
A descrição do produto em formato XML possui um total de 178 caracteres,
enquanto a descrição do produto em formato JSON possui apenas 107
caracteres, sendo o formato JSON 66% menor que o formato XML para este
caso.
Outra grande vantagem de se utilizar o JSON é que, de posse da string de
descrição do objeto, você precisa apenas chamar o método eval() do
JavaScript, para já ter o objeto pronto para o uso. Não há a necessidade de
percorrer toda a estrutura do arquivo XML, o que diminui a complexidade do
código JavaScript.
3.6 O que diferencia o Ajax
Em uma aplicação Web clássica, a seqüência de trabalho do usuário é definida
pelo código no servidor, e o usuário vai de uma página a outra, pontuado pelo
recarregamento da página inteira. Durante estes recarregamentos, o usuário
não pode continuar com seu trabalho. Em uma aplicação Ajax, o fluxo de
trabalho é pelo menos em parte definida pela aplicação cliente, e a
comunicação com o servidor é feita em segundo plano enquanto o usuário
prossegue com seu trabalho.
O navegador Web é um ambiente flexível e complacente, e funcionalidades
Ajax e não Ajax podem ser misturadas na mesma aplicação.
O que diferencia o Ajax não são as tecnologias que ele emprega, mas o
modelo de interação que ele permite por meio do uso dessas tecnologias. O
modelo de interação baseado na Web como qual estamos acostumados não é
adequado para aplicativos soberanos, e novas possibilidades começam a
surgir à medida que nos afastamos deste modelo de interação.
Existem ao menos dois níveis nos quais Ajax pode ser utilizado, e diversas
posições entre estes à medida que abandonamos a clássica abordagem
77
baseada em páginas. A estratégia mais simples é desenvolver componentes
baseados no Ajax amplamente auto-suficientes e que possam ser adicionados
a uma página Web com algumas instruções e importações de script. Lista de
operações na bolsa de valores, calendários interativos, e janelas de bate-papo
talvez sejam aplicativos típicos deste tipo de componente. Ilhas de
funcionalidade do tipo aplicativo são embutidas em uma página Web do tipo
documento, como ilustrado na Figura 22.
Figura 22
Uma página com componentes Ajax embutidos [3].
A maioria das tentativas iniciais do Google em relação ao Ajax se enquadra
neste modelo. A lista suspensa do Google Suggest e o componente de mapas
no Google Maps são elementos interativos embutidos em uma página.
Se quisermos adotar Ajax de uma maneira mais ousada, podemos virar este
modelo de ponta-cabeça, desenvolvendo uma aplicação em que fragmentos do
tipo aplicativo e do tipo documento possam residir, como ilustra a Figura 23.
78
Figura 23
Uma aplicação Ajax em que ilhas de conteúdo do tipo documento podem
ser carregadas ou declaradas programaticamente.
Esta abordagem é mais parecida com uma aplicação desktop, ou até mesmo
com um gerenciador de janelas ou um ambiente de área de trabalho. O GMail
do Google se encaixa neste modelo, com mensagens individuais exibidas
como documentos dentro de uma superestrutura interativa do tipo aplicativo.
De alguma maneira, aprender as tecnologias é a parte fácil. O desafio
interessante no desenvolvimento com Ajax está em aprender como usá-las em
conjunto. Estamos acostumados a pensar em aplicações Web como
storyboards, e redirecionamos o usuário de uma página para outra seguindo
um roteiro predeterminado. Com funcionalidades do tipo aplicativo em nossa
aplicação Web, podemos fornecer ao usuário um tratamento mais refinado
sobre o negócio, o que pode permitir uma abordagem mais flexível de solução
de problemas para este trabalho.
Para obter os benefícios desta maior flexibilidade, temos que questionar boa
parte dos nossos hábitos de codificação. Um formulário HTML é o único modo
de um usuário entrar com informações? Deveríamos declarar todas as nossas
interfaces com o usuário em HTML? Podemos comunicar com o servidor em
resposta às interações do usuário tal como pressionamento de teclas e
movimentos do mouse, bem como o convencional clique do mouse? No ritmo
79
acelerado do mundo da tecnologia da informação, enfatizamos mais o
aprendizado de novas habilidades, mas devemos desaprender hábitos antigos
pode ser também igualmente importante.
3.7 Vantagens e desvantagens
Como acontece com a maioria das tecnologias, o seu sucesso depende do uso
que as pessoas lhes dão. Indiscutivelmente, usar Ajax levanta algumas
questões, tanto para os desenvolvedores de aplicações Web como para os
usuários das aplicações, que podem por em risco o seu uso, mas quando
usado corretamente, existem diversas vantagens que não podem ser ignoradas
por quem desenvolve aplicações Web, como demonstram os grandes sucessos
que se têm observado nos últimos anos, como é o caso do GMail e Google
Maps da Google.
3.7.1 Vantagens
As principais vantagens decorrentes do uso de Ajax são as observáveis pelos
usuários das aplicações que fazem uso desta abordagem. Do ponto de vista de
quem desenvolve uma aplicação Ajax as vantagens não são tão óbvias, não se
pode dizer que o seu desenvolvimento ou manipulação de dados seja
necessariamente mais simples, contudo estas não deixam de existir,
principalmente se considerar-se que o uso de Ajax pode alterar a forma como
questões de usabilidade serão abordadas no futuro.
3.7.1.1 Vantagens com relação à usabilidade
As vantagens mais visíveis para um usuário de uma aplicação Ajax são as que
dizem respeito a sua interatividade e usabilidade. O ganho na interatividade faz
com que o comportamento das aplicações Web se aproxime do das aplicações
desktop, possibilitando ações como drag and drop e dando no geral uma maior
fluidez a navegação entre diferentes páginas de uma mesma aplicação. Dentre
os aspectos que mais se destacam no nível da interatividade que Ajax
possibilita podemos citar:
80
3.7.1.1.1 Tempos de espera mais curtos
Não sendo necessário carregar toda a página novamente, há uma grande
redução na largura de banda gasta quando se compara uma requisição Ajax
com uma requisição HTTP convencional para carregar uma página.
Menor gasto de largura de banda implica tempos de espera inferiores, o que é
vantajoso para qualquer aplicação Web uma vez que não provoca tantas
quebras no acesso a informação.
3.7.1.1.2 Validações automáticas em formulários
Não é necessário esperar que a submissão do formulário termine para saber se
um dado identificador de usuário está disponível ou é válido. Através de Ajax, é
possível realizar a validação no servidor em tempo real de dados inseridos em
formulários. Identificadores de usuários, números seriais, CEP, CPF, RG e todo
tipo de dados que necessitam validação por parte do servidor, podem ser
validados no formulário antes mesmo do usuário realizar a submissão do
mesmo.
Figura 24
Validação automática no servidor de nome de usuário em formulário
81
3.7.1.1.3 Páginas de confirmação
Podemos utilizar Ajax para eliminarmos páginas de confirmação, que são
essencialmente um desperdício, e existem somente porque um formulário Web
necessita ser submetido a fim de ser processado. O XMLHttpRequest resolve
isto e nos proporciona a opção de confirmarmos uma ação diretamente no
momento em que ela acontece.
3.7.1.1.4 Operações de Mestre-detalhe
Baseado em um evento originado pelo cliente, uma página pode obter
informações mais detalhadas sobre uma informação inicial. Por exemplo, podese obter detalhes de um determinado produto presente em uma lista de
produtos ao se passar o mouse sobre o nome do mesmo.
Figura 25
Exemplo de operação mestre-detalhe
82
3.7.1.1.5 Autocompletar em campos de formulário
Ao preencher campos de texto, é frequente que os dados que o usuário vai
inserir sejam previsíveis, quer seja por outro usuário já os ter inserido, como é
o caso de queries repetidas em sites de busca, quer seja por estarem
diretamente associados ao usuário em questão, como no preenchimento
automático do campo “para:” em um webmail usando a lista de contatos do
usuário. Neste tipo de campos faz sentido usar Ajax para ir buscar
dinamicamente as entradas mais freqüentes que comecem pelas letras que o
usuário está digitando, reduzindo assim o tempo necessário para escrever
entradas de texto longas e eventualmente ajudando o usuário a escrever aquilo
que pretende quando este não sabe exatamente o que escrever (quer seja um
endereço de e-mail ou uma palavra-chave de uma pesquisa).
Figura 26
Exemplo de autocompletar em campo no Google GMail.
3.7.1.1.6 Manipulação de dados mais interativa
Quando se pretende executar ações como reordenar uma lista de resultados
ou realizar qualquer tipo de filtragem, pode valer à pena usar Ajax para não ter
de carregar a página inteira novamente. Este tipo de situação aplica-se a todos
os acessos a dados que dependem fortemente do input do usuário.
3.7.1.1.7 Navegação em estruturas hierárquicas profundas
83
Às vezes é inviável carregar todos os dados relacionados com um assunto em
uma determinada página, tendo que remeter informações adicionais para nós
mais profundos na hierarquia de conteúdo que está sendo apresentada. Um
exemplo desta situação é nos tópicos de alguns fóruns de discussão nos quais
as respostas estão encadeadas, isto é, é possível responder a uma resposta
de outro usuário dentro de um tópico, sendo que não é viável mostrar toda a
árvore de respostas, mostrando-se apenas um nível da árvore de cada vez.
Nestas situações é vantajoso usar Ajax para expandir um nó da árvore, em
oposição a abrir uma página nova com o conteúdo (respostas) deste nó.
3.7.1.1.8 Interação do usuário com a aplicação
Ações como votar em uma enquete e ver imediatamente os totais da votação
ou fazer uma pergunta por meio de um formulário on-line, ganham uma
dimensão completamente diferente quando a resposta do site é imediata. O
uso de Ajax neste tipo de ações encoraja os usuários a darem opinião ao site,
o que promove a aproximação usuário-site e leva os criadores do site a
adequarem-se melhor as necessidades dos seus usuários.
3.7.1.1.9 Rápida interação entre usuários
Em aplicações de postagem de mensagens que criam discussões imediatas
entre usuários, forçar o usuário a dar refresh na página a todo o momento a fim
de verificar a existência de alguma resposta não é uma boa prática. As
respostas deveriam ser imediatas, o usuário não deveria ter que dar refresh na
página obsessivamente. Com Ajax é possível monitorar o servidor em busca de
novas informações e informá-las ao usuário no momento em que ocorrem. O
GMail inovou o antigo “refresh mail box” , presente nas antigas contas de email do Hotmail e Yahoo, notificando a presença de novas mensagens de
forma instantânea.
3.7.1.1.10
Avançados controles e UI Widgets
Controles como os de árvores, menus, e barras de progressão podem ser
providos sem a necessidade de refresh da página.
3.7.1.1.11
Recarregamento de informações
84
Páginas podem obter informações atualizadas do servidor sem a necessidade
de refresh. Informações como: placares de jogos, cotações de ações, previsão
do tempo ou outras informações especificas.
Figura 27
Exemplo de busca de informações atualizadas no servidor.
3.7.1.2 Desempenho e compatibilidade
Os ganhos em usabilidade de Ajax são muitos, mas convém não esquecer que
já era possível ter elevados índices de interatividade recorrendo a outras
tecnologias. O uso de applets Java ou de elementos Flash em sites não é uma
novidade e já era possível através destes melhorar a experiência do usuário ao
visitar um site, porém há dois aspectos a serem levados em consideração
nestes tipos de elementos: por um lado, tratam-se de elementos que
computacionalmente são, muitas vezes, muito pesados para um computador
processar, limitando assim o número de usuários que conseguem tirar proveito
do seu uso; por outro lado, estes elementos frequentemente requerem a
instalação de software adicional (plug-ins) no computador do usuário, que
muitas vezes não é desejável (tempo necessário para download do software e
85
espaço que ocupa, entre outros). Com Ajax estas questões não são tão
importantes, uma vez que a maioria dos sistemas já suportam todos os
elementos necessários para a visualização de um site em Ajax sem qualquer
tipo de software adicional.
3.7.1.3 Dispositivos móveis
Uma outra aplicação de Ajax que já começa a surgir é a que diz respeito ao
seu uso em dispositivos móveis. Além das questões de usabilidade, há de se
considerar nestes dispositivos o ganho em termos de consumo de tráfego, já
que em dispositivos móveis esta questão se coloca em duas vertentes: tempo
de carregamento e custos associados. Recentemente, os desenvolvedores do
navegador Opera lançaram um toolkit que permite lidar com este tipo de
requisições de uma forma mais transparente, de modo que não seja necessário
desenvolver sites específicos para determinados sistemas operacionais, como
é
feito
atualmente.
Este
toolkit
traz
ainda
grandes
benefícios
no
desenvolvimento de interfaces para smart phones e uma vez que a tecnologia
Ajax está apenas agora ganhando notoriedade é provável que venha a surgir
maior suporte para este tipo de dispositivos.
3.7.1.4 Web Standards
Com exceção da linguagem de programação JavaScript, todas as outras
tecnologias associadas ao termo Ajax, como: HTML, XML, CSS, DOM e
XMLHttpRequest são padrões W3C (World Wide Web Consortium).
3.7.1.5 Independência de tecnologia do lado servidor
Pode ser utilizada qualquer tecnologia do lado servidor. A abordagem Ajax se
concentra na camada de apresentação no lado cliente.
3.7.1.6 Inúmeros frameworks de qualidade
Existem inúmeros frameworks Ajax.
86
3.7.1.7 Adoção maciça da indústria
Ajax está sendo amplamente aceito pela indústria. Empresas como Google,
Yahoo! e Microsoft são exemplos de empresas que estão utilizando Ajax em
praticamente todas suas novas aplicações.
3.7.2 Desvantagens
Como em qualquer tecnologia, Ajax não deixa de ter as suas desvantagens. A
maioria destas desvantagens pode ser contornada pelos desenvolvedores.
Parte destas desvantagens deve-se também ao fato de Ajax ser usado em
contextos em que não é adequado. Muitos destes problemas irão desaparecer
assim que o Ajax for ganhando maturidade. Assim que a comunidade de
desenvolvedores for ganhando experiência na construção de aplicações Web
com Ajax, provavelmente serão documentados cada vez mais, melhores
práticas, design patterns e guias sobre o assunto.
3.7.2.1 Desvantagens em relação à usabilidade
3.7.2.1.1 Botão voltar e favoritos
Algumas questões envolvendo a atualização dos dados utilizando Ajax, são os
problemas do não funcionamento correto do botão “Voltar” do navegador em
alguns casos, e a URL na barra de endereços do navegador não refletir o
estado real da aplicação, o que pode ocasionar problemas de bookmarking,
deixando o usuário sem saber em que parte do site ele se encontra somente
visualizando a barra de endereços do navegador Web.
Apesar de haver implementações e frameworks que tratem destas questões, a
maioria das aplicações não tem esse cuidado.
3.7.2.1.2 Feedback ao usuário
Uma questão que se prende com a navegação entre páginas é o fato de não
ser dado feedback ao usuário sobre o estado das suas requisições, isto é, se a
página que o usuário quer acessar está efetivamente a ser aberta. Por
exemplo, é importante para o usuário saber que os dados que ele acabou de
enviar para o sistema estão sendo processados, porque os mecanismos de
feedback convencionais como, uma ampulheta girando ou a barra do
87
navegador sendo preenchida não se aplicam ao XMLHttpRequest. Uma técnica
utilizada é a troca do texto do botão de submissão por um texto do tipo
“Atualizando...”, evitando que o usuário clique no botão de submissão do
formulário repetidas vezes esperando por uma resposta.
Figura 28
Exemplos de feedback ao usuário
3.7.2.1.3 Scrolling
Há a questão do scrolling, numa página longa em que seja necessário rolar o
scroller da página para ver um determinado conteúdo, caso o mecanismo Ajax
retire um parágrafo acima do conteúdo que está sendo visualizado todo o texto
será "puxado" para cima.
3.7.2.1.4 Rompimento das convenções existentes
Ainda
que
existam novas
possibilidades em
nível de
interface,
os
desenvolvedores devem ter o cuidado de não romper completamente com as
convenções existentes uma vez que correm o risco dos usuários não saberem
como utilizar os seus sites.
3.7.2.1.5 Indexação
Ainda deve-se levar em conta o fato de que a indexação dos conteúdos por
parte de motores de busca não é possível nos conteúdos que são acessíveis
através de Ajax. Para estes casos seria necessário disponibilizar uma versão
acessível sem usar Ajax.
3.7.2.1.6 Percepção do usuário
88
Outra questão é a dos usuários não notarem que determinada parte da página
que estão visualizando foi atualizada.
Figura 29
Comparativo entre os modelos de interação
Pode-se aliviar este problema utilizando-se uma variedade de técnicas visuais
que focam nossa percepção a estas áreas atualizadas de forma sutil, somente
para que o usuário perceba que aquela parte da página foi atualizada.
Figura 30
Focando a percepção as áreas atualizadas de forma sutil
3.7.2.1.7 Eliminar aceitação
Não se deve utilizar Ajax para eliminar aceitação. O objeto XMLHttpRequest
pode ser utilizado para salvar automaticamente os dados de um formulário,
sem a necessidade do usuário clicar em um botão de “Confirmar” ou “Salvar”.
89
Isso parece ótimo, mas entra em conflito com um principio muito importante da
usabilidade, que trata do direito do usuário explorar a interface da aplicação
adicionando ou editando informações sem necessariamente atualizar nada
realmente. Ao atualizar os dados automaticamente, não se dá ao usuário a
chance de poder desfazer o que ele fez.
3.7.2.1.8 Quebrar o foco do usuário
Deve-se evitar quebrar o foco do usuário do que ele realmente esta tentando
fazer. Por exemplo, no caso de um site de pesquisa que traz os resultados a
cada caractere digitado pelo usuário. Um usuário está buscando pela palavra
“usabilidade”. Seu primeiro foco de atenção é na escrita da palavra
“usabilidade” e em segundo lugar encontrar um artigo sobre o tema. Se o site
começa a trazer resultados à medida que ele começa a digitar, isto irá quebrar
a sua atenção para o que estava tentando fazer.
Ele digitou “u” e o site trouxe inúmeros resultados que contenham a letra “u” em
alguma parte do texto, se ele tiver sorte o artigo que ele procura aparecerá no
topo da lista, mas o que é mais provável é que apareça um monte de artigos
irrelevantes. Isto não só atrapalhou a tarefa que ele estava executando como
também o fez perder tempo procurando algo que não precisava.
Escrever “usabilidade” leva em torno de uns 2 segundos para uma pessoa
normal, mas com o mecanismo de busca interrompendo, leva em torno de 4 à
10 segundos.
Uma solução seria utilizar um intervalo de tempo, durante um tempo o sistema
não iria fazer nada, usualmente 0.6 segundos. Isto faria com que houvesse
tempo para completar a palavra e extrair os benefícios do XMLHttpRequest.
3.7.2.2 Desvantagens em relação à implementação
Relativo à implementação, existem vários aspectos que sofrem com o uso de
Ajax.
3.7.2.2.1 Aumenta a quantidade dos testes
Uma vez que a execução de parte do código depende da máquina do cliente, é
necessário ter um maior cuidado a nível de testes, para garantir que as
90
aplicações Ajax funcionem em todos os sistemas e navegadores Web a que o
sistema se destina.
3.7.2.2.2 Adiciona complexidade
Em um sistema Web clássico, toda e qualquer ação do usuário implica no
processamento de formulários, no carregamento de novas páginas, sendo algo
bastante linear. O estado dos dados do usuário (informações preenchidas em
formulários e que foram enviadas para validação, nas preferências pessoais ou
no carrinho de compras) é constantemente recuperado no lado servidor,
analisado, colocado no contexto de visualização e então reenviado ao cliente.
Ao colocarmos XMLHttpRequest de forma assíncrona, precisamos achar um
lugar para guardarmos as informações, sendo comum não termos a mão tudo o
que costumamos ter (request, response, session, conexão com o banco, etc.),
já que o processamento é realizado por um caminho diferente de uma
requisição normal.
Desenvolvedores do lado servidor necessitam saber o que a lógica de
apresentação vai necessitar nas páginas HTML no lado cliente, assim como a
lógica do lado servidor.
3.7.2.2.3 Debuging difícil
Encontrar problemas em código JavaScript costuma ser uma tarefa bastante
difícil, pois basicamente o que se é possível fazer, é utilizar a função
alert(mensagem), ou então utilizar document.write(mensagem), para saber
qual valor contém determinada variável.
Os navegadores Web mais modernos, especialmente os da família Mozilla,
contém um relatório de erros relativamente preciso, o que ajuda a encontrar
mais rapidamente o ponto de falha no código. No Internet Explorer, as coisas
complicam um pouco, pois seu JavaScript console muitas vezes não aponta
para o local correto da falha no código.
Atualmente já existem alguns depuradores de JavaScript, ainda não estão no
mesmo nível que os encontrados em outras linguagens de programação, mas
já facilitam em muito a vida dos desenvolvedores. Serão apresentados alguns
mais a diante.
3.7.2.2.4 Código-fonte fácil de pegar
91
Assim como o código HTML, código JavaScript precisa ser enviado ao cliente
para processamento, ficando assim disponível aos olhos do usuário mais
curioso. Dada a natureza do JavaScript isto não acarreta em um problema mais
sério, como segurança, mas algumas empresas podem querer criar problemas
com isso. O fato é que não podemos compilar um código em JavaScript, então
a única solução acaba sendo a ofuscação de código-fonte.
3.7.2.2.5 Disponibilidade do objeto XMLHttpRequest
Um dos maiores desafios diante dos desenvolvedores Ajax é o de como
proceder no caso da ausência do XMLHttpRequest. Enquanto a maioria dos
navegadores modernos suportam o XMLHttpRequest, sempre existe uma
minoria de usuários utilizando navegadores que não suportam tal recurso, ou
que as suas configurações de segurança estão configuradas para bloquear o
XMLHttpRequest. Se estivermos desenvolvendo um sistema que irá rodar
somente em uma intranet corporativa, podemos nos dar ao luxo de
especificarmos quais navegadores irão suportar a aplicação e assumirmos que
o
XMLHttpRequest
sempre
estará
disponível.
Mas
se
estivermos
desenvolvendo uma aplicação para o público em geral, e você presumir que o
XMLHttpRequest estará sempre disponível, você estará bloqueando o acesso
dos usuários que possuam navegadores antigos, navegadores para pessoas
com deficiências, ou navegadores leves com pouca capacidade como os que
rodam em alguns dispositivos portáteis, de acessarem a sua aplicação.
Uma solução é a construção de uma aplicação tolerante a falhas, que mantém
a aplicação funcional mesmo em navegadores que não suportem o
XMLHttpRequest. Um exemplo seria a construção de uma outra versão da
aplicação sem o uso do XMLHttpRequest, então no momento do acesso do
usuário à aplicação, pode-se verificar o suporte ou não do XMLHttpRequest no
navegadores do usuário e direcioná-lo a devida versão.
3.7.2.2.6 Sobrecarga do servidor
Uma pesquisa normal do site de buscas do Google provoca uma requisição ao
servidor, que ocorre quando o usuário submete o formulário de consulta.
Porém, o Google Suggest, que tenta autocompletar o termo de pesquisa à
92
medida que o usuário digita os caracteres, realiza várias requisições ao
servidor, uma para cada caractere digitado no formulário de consulta.
Ao desenvolver-se uma aplicação com Ajax deve-se estar ciente de quantas
requisições serão feitas ao servidor e qual o impacto isto irá causar sobre o
mesmo. Pode-se amenizar o impacto sobre o servidor criando um buffer de
requisições e um cache das respostas do servidor no cliente, quando isto for
possível.
3.7.2.2.7 Lidando com assincronia
É muito importante entender que não existe garantia de que as requisições
feitas através do objeto XMLHttpRequest ao servidor irão se completar na
mesma ordem na qual foram solicitadas. Porém, pode-se assumir que elas não
irão e projetar a aplicação com isto em mente. Por exemplo, em um carrinho de
compras de um site de vendas, pode-se guardar a data da última atualização
do carrinho, evitando assim que dados mais antigos sobrescrevam os mais
atuais.
3.8 Segurança
As aplicações Ajax têm sido cada vez mais desejadas por clientes ávidos por
ver interatividade e funcionalidade em uma ambiente Web, no qual a regra
costuma ser clicar e esperar. O que estes clientes muitas vezes esquecem de
dizer é que os dados que estão por trás das aplicações é imprescindível
independentemente de quão interativa é a aplicação.
Na prática, todas as recomendações de segurança que servem para um
aplicativo Web tradicional, também se aplicam normalmente a um aplicativo
Ajax. A grande diferença é que uma aplicação tradicional acessa o servidor
somente para buscar conteúdo, enquanto uma aplicação Ajax pode também
buscar dados e scripts para a execução. Essa diferença faz com que as
aplicações Ajax estejam mais expostas a atacantes do que outras aplicações
Web tradicionais.
93
3.8.1 Formas de Interação de uma Aplicação Ajax
Uma aplicação Ajax possui varias formas de interagir com o servidor, e
dependendo da forma utilizada, diferentes abordagens de ataque podem ser
utilizadas para quebrar a segurança.
A forma de Interação mais comum é a troca de dados. Neste caso o maior risco
é a superexposição de métodos de negócio que podem ser explorados de
forma maliciosa por atacantes.
Outra forma de interação comum é a troca de conteúdo HTML com o servidor,
em que os riscos são os mesmos de uma aplicação Web tradicional.
A forma menos comum, mas também possível, é a troca de código JavaScript
para
ser
dinamicamente
executado,
sendo
neste
caso,
a
principal
vulnerabilidade a injeção de fragmentos de script nos parâmetros.
A Tabela 2 trás com mais detalhes os possíveis tipos de interação e as
principais vulnerabilidades de cada um.
Tabela 2
Interação
Dados
Conteúdo
Vulnerabilidades por tipo de interação.
Descrição
Possíveis Ataques
A aplicação Ajax busca
O atacante acessa a URL utilizada para obter os
no servidor dados em
dados da aplicação Ajax passando diferentes
formato XML, JSON ou
parâmetros visando obter informações cujo acesso
texto plano e utiliza os
não era autorizado.
mesmos para modificar
O atacante, de posse dos scripts que irão processar
dinamicamente a página
a informação vinda do servidor, envia dados para o
HTML utilizando
servidor que fará o processamento dos dados tenha
JavaScript.
algum efeito malicioso em outros usuários.
A aplicação Ajax acessa
São enviados parâmetros maliciosos de forma a
uma URL que retorna um
interferir no conteúdo que será gerado
fragmento de conteúdo
dinamicamente. Isto pode ser utilizado para roubar a
em formato HTML, e este
sessão de um usuário e passar pela autenticação do
conteúdo é colocado
sistema.
dentro de uma tag <DIV>
Quando o conteúdo vem acompanhado de algum
ou <SPAN>.
script para ser executado dinamicamente, se
aplicam os mesmos ataques de interação por script.
Script
É gerado dinamicamente
Juntamente com os parâmetros, são enviados
um script para ser
fragmentos de script, para que o código possa ser
executado pela aplicação
executado no navegador Web seja gerado de forma
94
Ajax quando esse for
alterada, permitindo a inserção de comandos
recebido do servidor. A
maliciosos visando, por exemplo, roubar a sessão do
execução é feita pela
usuário.
função eval().
Um fator que favorece bastante o atacante é a posse de todo o código que é
executado no cliente. O acesso a todo o código JavaScript da aplicação ajuda
bastante na investigação de falhas que podem vir a ser exploradas para
obtenção de informações não autorizadas. Uma regra interessante é a
utilização de JavaScript apenas para acessar regras de negócio que estão no
servidor “por baixo dos panos”. Qualquer regra de negócio que estiver somente
no cliente pode ser facilmente burlada.
Uma forma de proteger o código em JavaScript contra a leitura é a ofuscação,
porém apesar do código estar embaralhado, o atacante tem acesso a ele. De
qualquer forma, ofuscar é melhor do que deixá-lo aberto.
As aplicações Ajax que trocam dados com o servidor costumam disponibilizar,
através de uma URL, o acesso a uma função que recebe os parâmetros da
requisição HTTP e retorna as informações em um formato especifico,
normalmente XML ou JSON. O grande problema é que essa URL não estará
disponível apenas para a aplicação Ajax, mas também para quem quiser
acessá-la de forma indiscriminada. Se a aplicação não contar com um
mecanismo de controle de acesso robusto, os atacantes podem fazer uso
destas funcionalidades para obterem acesso a informações não autorizadas.
4 A Aplicação UFSC Maps
Como resultado da aplicação dos conhecimentos adquiridos com a realização
deste trabalho e vista a oportunidade de agregar algum valor ao site da UFSC,
foi desenvolvida uma aplicação que visa georeferenciar o campo da UFSC de
uma
maneira
interativa
e
responsiva,
aplicando
a
abordagem
de
desenvolvimento Ajax.
95
4.1 Tecnologias Empregadas
Para o desenvolvimento da aplicação foram empregadas as seguintes
tecnologias:

Google Maps API41 para apresentação do mapa.

ExtJS42 para a camada cliente;

DWR43 para a comunicação do cliente com o servidor através de
chamadas assíncronas.

Java/JEE44 na parte do servidor.

Hibernate45 para persistência dos dados no lado servidor.

Spring46 para injeção de dependências no lado servidor.

Apache Tomcat47 como servidor Web.

MySQL48 como banco de dados.
4.2 Telas
A aplicação pode ser dividida em duas partes: a tela principal e as telas de
cadastro.
4.2.1 Tela Principal
No momento que o usuário entra na aplicação é apresentada a seguinte
interface, como ilustra a Figura 31. Esta tela apresenta um toolbar na região
superior, um menu do tipo Acordeão a esquerda e um mapa na região central.
41
Disponível em http://code.google.com/apis/maps/
42
Disponível em http://extjs.com/
43
Disponível em http://getahead.ltd.uk/dwr/
44
Disponível em http://java.sun.com/
45
Disponível em http://www.hibernate.org/
46
Disponível em http://springframework.org/
47
Disponível em http://tomcat.apache.org/
48
Disponível em http://www.mysql.com/
96
Figura 31
Tela inicial da aplicação.
O mapa da região central vem carregado inicialmente sobre o Campus
Trindade da UFSC com um nível de zoom pré-definido e um polígono de cor
azul-clara delimitando a área do mesmo.
O menu do lado esquerdo, chamado “Mapeamentos”, possui os mapeamentos
dos pontos de interesse referentes a instituição UFSC, como Centros de
Ensino, Fundações, Reitoria e demais pontos pertencentes ao campus. Este
menu é populado assincronamente e ao ser expandido adiciona ao mapa os
pontos de interesse cadastrados para aquele item de menu, como mostra a
Figura 32.
Ao se clicar tanto no ícone do marcador no mapa, quanto no texto do menu
Mapeamentos, é aberta uma janela com informações sobre o ponto mapeado.
Estas informações também são recuperadas de forma assíncrona.
97
Figura 32
Menu de mapeamentos expandido.
O toolbar superior possui diversos botões do tipo Toggle Button, cada botão
representa os mapeamentos para um tipo de área de interesse, os tipos de
área de interesse apresentados neste toolbar são mapeamentos mais
genéricos. Da esquerda para a direita os botões representam os seguintes
tipos de marcadores:

Acessibilidade (Rampas, orelhões para deficientes, etc.);

Alimentação (Restaurantes, lanchonetes, bares, cafés, etc.);

Bancos e Caixas Eletrônicos;

Hospitais e Farmécias;

Fotocópias (Xerox, impressões, etc.);

Pontos de Ônibus;

Pontos de Taxi;

Estacionamentos;

Postos de Combustível;

Mecânicos;

Telefones Públicos;
98

Informações;

Banheiros;

Agencias dos Correios;

Salões de Beleza;

Lojas;

Artes e Cultura;

Moradia Estudantil;

Polícia e Segurança;

Esportes;

Praças, Parques e Bosques.
Ao clicar em um destes botões, o botão fica selecionado e são apresentados
no mapa os mapeamentos referentes aquele tipo de mapeamento, ao se clicar
novamente no mesmo botão, deselecionando o mesmo, são removidos os
mapeamentos referentes aquele tipo de mapeamento, como ilustra a Figura 33.
Figura 33
Toolbar com botões selecionados.
99
4.2.2 Tela de Cadastro
Existem duas telas de cadastro: a de cadastro de Marcadores e a de cadastro
de Polígono.
4.2.2.1 Cadastro de Marcador
A tela de cadastro de marcador possui um botão na parte superior para
exibição, ou não, dos marcadores já cadastrados. Se o botão estiver
selecionado são apresentados os marcadores já cadastrados e é possível
alterar as informações dos mesmos, ao se clicar sobre o marcador, como
ilustra a Figura 34.
Figura 34
Tela de atualização de marcador.
Para cadastrar um novo marcador deve-se clicar com o mouse na área de
interesse no mapa que se deseja cadastrar. O sistema criará automaticamente
100
um novo marcador, de cor amarela para diferenciar dos já cadastrados, e uma
janela de informação com um formulário de cadastro será exibida com os
seguintes campos:

Latitude (Já vem preenchida automaticamente);

Longitude (Já vem preenchida automaticamente);

Tipo de marcador (Caixa de seleção com os tipos previamente
cadastrados);

Website;

Imagem (Mecanismo para o upload de imagem de forma assíncrona);

Descrição (Editor de HTML);
Figura 35
Tela de cadastro de marcador.
Assim que o cadastro é efetuado, de forma assíncrona e com sucesso, o
marcador automaticamente muda para a cor vermelha. Também é possível
arrastar e soltar um marcador pelo mapa, ao se soltar o marcador a janela de
101
atualização será apresentada já com os novos valores de latitude e longitude
para que o usuário confirme, ou não, a alteração.
4.2.2.2 Cadastro de Polígono
A tela de cadastro de polígono apresenta também um botão superior para
visualização dos pontos que integram as delimitações do polígono. Se este
botão estiver selecionado pode-se arrastar e soltar os pontos já cadastrados
ajustando assim as delimitações do polígono. Para criar um novo ponto é
necessário apenas clicar sobre o mapa que o novo ponto será criado
automaticamente. A Figura 36 ilustra a tela de cadastro de polígono.
Figura 36
Tela de cadastro de polígono.
102
5 Conclusão
5.1 Considerações finais
O desenvolvimento de aplicações mais interativas e responsivas se
assemelhando cada vez mais das aplicações desktops deve se intensificar
cada vez mais nos próximos anos. Não como uma promessa futura, mas como
realidade.
Vimos os sistemas desktop sendo migrados para o ambiente Web nos últimos
tempos. Nas intranets das empresas isso foi quase que uma regra geral. Se
por um lado foram facilitadas a manutenção e a disponibilidade das aplicações,
por outro lado se perdeu muito na interatividade e responsividade das mesmas.
Agora é a vez destes aplicativos Web se tornarem mais interativos e
responsivos, está na hora de se pensar em usabilidade. Só o fato de ser um
sistema Web já não é mais suficiente, os usuários buscam a mesma
interatividade que possuíam nos seus aplicativos desktop. E isto e mais um
pouco é possível através do uso de Ajax.
5.2 Sugestões para futuros trabalhos
A disponibilização da aplicação no site da UFSC seria um diferencial para a
universidade perante as outras universidades federais, pois seria a primeira a
possuir tal ferramenta.
Como sugestões para a aplicação de georeferenciamento do campus, pode-se:

Continuar o mapeamento dos pontos de interesse.

Criar uma espécie de pontos temporários, para o mapeamento de
eventos. Por exemplo, quando ocorrer algum evento no campus, seria
apresentada a localização geográfica e outras informações do mesmo
no mapa interativo, auxiliando na localização do mesmo com maior
facilidade. Após o termino do evento este ponto de interesse seria
removido da aplicação.

Criar “visões” do mapa associadas a cada usuário. Por exemplo, com
base nas matérias que o aluno está cursando no semestre, referenciar
103
os pontos de interesse para aquele aluno em especifico, como
localização das salas de aulas para cada matéria.

Criar um mecanismo de busca semântica para a aplicação. Por
exemplo, ao se procurar por “EEL103”, o sistema interpretar tal
informação e apontar no mapa o prédio da engenharia elétrica. Ou se
procurarmos por “INE5641”, o sistema saberia que esta informação é
referente a matéria “Comércio Eletrônico” e nos indicaria o centro de
ensino, o prédio e a sala onde esta matéria é ministrada, a sala do
professor que ministra tal disciplina, etc.
104
Referências Bibliográficas
[1]
OLIVEIRA, Felipe A.. Web 2.0, Ajax e SOA: uma nova perspectiva.
2006. Disponível em: http://scaphe.wordpress.com/2006/08/19/soa/. Acesso
em: 29 de Fevereiro de 2008.
[2]
COOPER,
Alan.
Your
Program's
Posture.
Disponível
em:
http://www.cooper.com/articles/art_your_programs_posture.htm. Acesso em: 29
de Fevereiro de 2008.
[3]
CRANE, Dave; PASCARELLO, Eric; JAMES, Darren. Ajax in Action.
Greenwich: Manning Publications, 2006. ISBN 8576051095
[4]
San
GARRET, Jesse James. Ajax: A New Approach to Web Applications.
Francisco:
Adaptive
Path,
2005.
Disponível
em:
https://www.adaptivepath.com/ideas/essays/archives/000385.php. Acesso em:
29 de Fevereiro de 2008.
[5]
WIKIPEDIA.
Desktop
Online.
Disponível
em:
http://pt.wikipedia.org/wiki/Desktop_online. Acesso em: 02 de Março de 2008.
[6]
ECMAScript Language Specification. Disponível em: http://www.ecma-
international.org/publications/files/ECMA-ST/Ecma-262.pdf. Acesso em: 21 de
Abril de 2008.
[7]
JSON. Disponível em: http://www.json.org. Acesso em: 21 de Abril de
2008.
[8]
O’REILLY, Tim. What Is Web 2.0 : Design Patterns and Business
Models for the Next Generation of Software. 2005. Disponível em:
http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web20.html. Acesso em: 29 de Abril de 2008.
[9]
McLAUGHLIN, Brett. Use a Cabeça! (Head Rush) Ajax. Alta Books,
2006. ISBN 8576081253
[10]
OLSON, Steven Douglas. Ajax com Java. Alta Books, 2007. ISBN
9788576081494
[11]
MAHEMOFF, Michael. Padrões de Projetos Ajax. Alta Books, 2007.
ISBN 9788576081371
105
[12]
SAMPAIO, Cleuton. Web 2.0 e Mashups: Reinventando a Internet.
Brasport, 2007. ISBN 9788574523385
106
Apêndice A
Ferramentas
Nos últimos anos houve grandes evoluções no sentido de tornar o
desenvolvimento de software do lado servidor mais fácil e robusto, enquanto
que o lado cliente foi praticamente ignorado.
A abordagem Ajax força os desenvolvedores de aplicações Web a trabalharem
com grandes quantidades de HTML, JavaScript, DOM e CSS.
Com advento de Ajax essa situação começou a mudar, estão surgindo diversas
ferramentas para auxiliar o trabalho dos desenvolvedores, tornando o
desenvolvimento de aplicações Ajax um pouco mais fáceis.
Este apêndice traz um resumo da linha atual de ofertas, são apresentadas
somente uma breve descrição da ferramenta, uma imagem da aplicação, o
endereço eletrônico oficial e o tipo de licença de uso.
A.1 IDEs e IDEs Plugins
A.1.1 Aptana
Aptana é baseado na IDE Eclipse49 e é focalizada no desenvolvimento Web,
com suporte a HTML, CSS e JavaScript, assim como opcionalmente a outras
tecnologias como PHP, Adobe Air, Ruby on Rails e iPhone. O Aptana Studio
está disponível como uma aplicação independente ou como plug-in para o
Eclipse.
Entre as características principais do Aptana Studio podemos destacar:

Assistente de código para JavaScript, HTML, e CSS.

Visualização de erros de sintaxe à medida que se escreve.

Debug de código JavaScript.

Já vem pré-configurado com diversos frameworks e bibliotecas
Ajax/Javascript.
49
Disponível em http://www.eclipse.org/
107

Possui diversos projetos de exemplo pré-configurados para diversos
frameworks e bibliotecas JavaScript.

Pré-visualização de estilos CSS com o editor CSS.

Extensível a partir de plug-ins.
Figura 37
Aptana Studio IDE
Site Oficial: http://www.aptana.com/
Licença: Possui uma versão comercial (Professional Edition) e uma gratuita
(Community Edition sob licença Eclipse Public License)
A.1.2 JSEclipse
É um plugin para Eclipse focado na edição de JavaScript.
Entre as características principais do JSEclipse podemos destacar:

Assistente de código para JavaScript.

Visualização de erros de sintaxe à medida que se escreve.

Já vem pré-configurado com diversos frameworks e bibliotecas
Ajax/Javascript.
108
Figura 38
JSEclipse
Site Oficial: http://labs.adobe.com/technologies/jseclipse/
Licença: Eclipse Public License
A.1.3 MyEclipse
É uma IDE baseada no Eclipse para desenvolvimento Java, mas possui uma
serie de ferramentas para o desenvolvimento Ajax, na verdade o MyEclipse foi
o pioneiro na adição de recursos para Ajax no ambiente do Eclipse.
Entre
as
características
principais
do
MyEclipse
com
relação
ao
desenvolvimento Ajax podemos destacar:

Assistente de código para JavaScript, HTML, e CSS.

Visualização de erros de sintaxe à medida que se escreve.

Debug de código JavaScript.

Pré-visualização de estilos CSS com o editor CSS.

DOM Inspector.

Extensível a partir de plug-ins.
109
Figura 39
MyEclipse
Site Oficial: http://www.myeclipseide.com/
Licença: Comercial
A.2 DOM Inspectors
A.2.1 Firefox DOM Inspector
Firefox DOM Inspector é uma ferramenta para inspeção de DOM que vem
embutida no navegador Mozilla Firefox e está disponível através do menu
ferramentas.
110
Figura 40
Firefox DOM Inspector
Site Oficial: http://getfirefox.com/
Lisença: Mozilla Public Licence
A.2.2 Internet Explorer Developer Toolbar
O internet Explorer Developer Toolbar é um conjunto de ferramentas que inclui
um inspetor de DOM.
111
Figura 41
Internet Explorer Toolbar
Site
Oficial:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d4511-bb3e-2d5e1db91038&displaylang=en
Licença: Gratuito através do site da Microsoft.
A.3 Debuggers
A.3.1 Venkman JavaScript Debugger
Venkman é um depurador em JavaScript. Faz parte do Mozilla Application
Suite. Ele também está disponível como uma extensão do Mozilla Firefox.
Venkman recebe este nome pelo Dr. Peter Venkman interpretado por Bill
Murray nos filmes Ghostbusters e Ghostbusters II.
112
Figura 42
Venkman JavaScript Debugger
Site Oficial: http://www.mozilla.org/projects/venkman/
Licença: Mozilla Public Licence
A.3.2 Firebug debug extension for Firefox
O Firebug é uma extensão para o navegador Mozilla Firefox criada por Joe
Hewitt e prove diversas funcionalidades como edição, logging e debugging de
JavaScript, inspeção e edição de HTML, CSS e DOM, monitoramento de
atividade de rede, entre outros.
113
Figura 43
Firebug
Site Oficial: http://www.getfirebug.com/
Licença: Mozilla Public Licence
A.4 Javascript Unit-Testing
A.4.1 Scriptaculous Unit-Testing
Scriptaculous Unit-Testing é um framework de teste unitário incluso no
framework Scriptaculous.
Site Oficial: http://wiki.script.aculo.us/scriptaculous/show/UnitTesting
Licença: MIT
A.4.2 JsUnit (Hieatt)
114
O JsUnit de Edward Hieatt é um framework de testes que segue a arquitetura
xUnit para frameworks de teste. È basicamente uma versão do JUnit50 para
JavaScript.
Site Oficial: http://www.jsunit.net/
Licença: LGPL, GPL e Mozilla Public Licence
A.4.3 JsUnit (Schaible)
O JsUnit de Jörg Schaible é um framework de testes que segue a arquitetura
xUnit para frameworks de teste. É uma versão em JavaScript do JUnit 3.8.1.
Site Oficial: http://jsunit.berlios.de/
Licença: Apache Software License 2.0
50
Disponível em http://www.junit.org/
115
Apêndice B
Frameworks e bibliotecas
Nos últimos tempos houve uma rápida proliferação dos ambientes de
desenvolvimento Ajax e JavaScript, desde pequenos utilitários empacotadores
para compatibilidade com múltiplos navegadores até soluções completas de
ponta a ponta para cliente e servidor.
Este apêndice traz um resumo da linha atual de ofertas, são apresentadas
somente uma breve descrição retirada do site dos autores do framework ou
biblioteca, o endereço eletrônico oficial e o tipo de licença de uso.
B.1 Dojo
“Ajax, events, packaging, CSS-based querying, animations, JSON, language utilities,
and a lot more. All at 24K (gzipped).
Skinnable, template-driven widgets with accessibility and localization built right in—the
way you want it. From accordions to tabs, we have you covered.
Inventive & innovative code and widgets. Visualize your data with grids and charts.
Take your apps offline. Cross-browser vector drawing. And a lot more.”
Site Oficial: http://dojotoolkit.org/
Licença: Academic Free v2.1
B.2 ExtJS
“Documentation. Design. Clean Code. A foundation you can build on”
Site Oficial: http://extjs.com/
Licença: LGPL
B.3 Yahoo! UI
“The Yahoo! User Interface (YUI) Library is a set of utilities and controls, written in
JavaScript, for building richly interactive web applications using techniques such as
DOM scripting, DHTML and AJAX. The YUI Library also includes several core CSS
116
resources. All components in the YUI Library have been released as open source under
a BSD license and are free for all uses.”
Site Oficial: http://developer.yahoo.com/yui/
Licença: BSD
B.4 Prototype
“Prototype is a JavaScript Framework that aims to ease development of dynamic web
applications.
Featuring a unique, easy-to-use toolkit for class-driven development and the nicest Ajax
library around, Prototype is quickly becoming the codebase of choice for web
application developers everywhere.”
Site Oficial: http://www.prototypejs.org/
Licença: MIT (código-fonte) e CC BY-SA (documentação)
B.5 Script.aculo.us
“script.aculo.us provides you with easy-to-use, cross-browser user interface JavaScript
libraries to make your web sites and web applications fly.”
Site Oficial: http://script.aculo.us/
Licença: MIT
B.6 JQuery
“jQuery is a new type of JavaScript library. jQuery is a fast, concise, JavaScript Library
that simplifies how you traverse HTML documents, handle events, perform animations,
and add Ajax interactions to your web pages. jQuery is designed to change the way that
you write JavaScript.”
Site Oficial: http://jquery.com/
Licença: MIT e GPL
B.7 Mochikit
117
“Mochikit makes JavaScript suck less”
Site Oficial: http://mochikit.com/
Licença: MIT e Academic Free v2.1
B.8 OpenRico
“JavaScript for Rich Internet Aplications”
Site Oficial: http://openrico.org/
Licença: Apache Software License 2.0
B.9 Quooxdoo
“qooxdoo is a comprehensive and innovative Ajax application framework. Leveraging
object-oriented JavaScript allows developers to build impressive cross-browser
applications. No HTML, CSS nor DOM knowledge is needed.
It includes a platform-independent development tool chain, a state-of-the-art GUI toolkit
and an advanced client-server communication layer.”
Site Oficial: http://qooxdoo.org/
Licença: LGPL e EPL
B.10
Mootools
“MooTools is a compact, modular, Object-Oriented JavaScript framework designed for
the intermediate to advanced JavaScript developer. It allows you to write powerful,
flexible, and cross-browser code with its elegant, well documented, and coherent API.”
Site Oficial: http://mootools.net/
Licença: MIT
B.11
Ruby on Rails
118
“Ruby on Rails is a open-source web framework that’s optimized for programmer
happiness and sustainable productivity. It lets you write beautiful code by favoring
convention over configuration”
Site Oficial: http://www.rubyonrails.org/
Licença: MIT
B.12
DWR - Direct Web Remoting
“DWR allows Javascript in a browser to interact with Java on a server and helps you
manipulate web pages with the results.
DWR is Easy Ajax for Java”
Site Oficial: http://getahead.org/dwr
Licença: Apache Software License 2.0
B.13
GWT - Google Web Toolkit
“Faster AJAX than you can write by hand.
Google Web Toolkit (GWT) makes it easier to write high-performance AJAX
applications. You write your front end in the Java programming language and GWT
compiles your source into highly optimized JavaScript. Writing web apps today is a
tedious and error-prone process. You spend 90% of your time working around browser
quirks, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX
components difficult and fragile. It doesn't have to be that way.”
Site Oficial: http://code.google.com/webtoolkit/
Licença: Apache Software License 2.0
119
Anexos
Anexo A – Código Fonte
O
código
fonte
do
projeto
UFSCMaps
se
encontra
no
arquivo
Aplicações_Ricas_com_Ajax_–_Código_Fonte.pdf
Anexo B – Artigo
O artigo referente ao trabalho de conclusão de curso se encontra no arquivo
Aplicações_Ricas_com_Ajax_–_Artigo.pdf
120