AJAX

De Wiki Canção Nova
Revisão de 10h04min de 22 de maio de 2009 por Marcusv (discussão | contribs) (Nova página: '''AJAX''' (acrônimo para ''Asynchronous Javascript ANd XML'') é o uso metodológico de tecnologia como Javascript e XML, para tornar páginas mais interativas com o usuário...)
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para: navegação, pesquisa

AJAX (acrônimo para Asynchronous Javascript ANd XML) é o uso metodológico de tecnologia como Javascript e XML, para tornar páginas mais interativas com o usuário de uma forma mais dinâmica e criativa na construção de aplicativos Web. O AJAX incorpora em seu modelo:

  • Apresentação baseada em padrões, usando XHTML e CSS;
  • Exposição e interação dinâmica usando DOM;
  • Intercâmbio e manipulação de dados usando XML e XSLT;

O modelo clássico de aplicação Web funciona assim: A maioria das ações do usuário na interface dispara uma solicitação HTTP para o servidor web. O servidor processa algo — recuperando dados, realizando cálculos, conversando com vários sistemas legados — e então retorna uma página HTML para o cliente. É um modelo adaptado do uso original da Web como um agente de hipertexto, porém o que faz a Web boa para hipertexto não necessariamente faz ela boa para aplicações de software.

Esta aproximação exige muito dos sentidos técnicos, porém não é capaz de fazer tudo que um usuário experiente poderia fazer. Enquanto o servidor está fazendo o seu trabalho, o que o usuário estará fazendo? A resposta mais óbvia será esperando. E a cada etapa do trabalho, o usuário aguarda mais uma vez.

Obviamente, se estivéssemos prjetando a Web à partir do zero para aplicações, não faríamos com que os usuários esperassem em vão. Por que a interação do usuário deveria parar a cada vez que a aplicação precisasse de algo do servidor, quando uma vez a interface carregada? Na realidade, por que o usuário deveria ver a aplicação ir ao servidor toda vez?

A maior vantagem das aplicações AJAX é que elas rodam no próprio navegador Web.

À partir de 2005, o AJAX foi muito importante para o desenvolvimento da WEB 2.0, levando à internet funções nunca antes imaginadas, que passariam por ficção há um pouco período de tempo atrás.

Os quatro princípios de AJAX

O modelo clássico de aplicação baseado em páginas está relacionado com muitas das estrururas que usamos, e também em nossas maneiras de pensar. Vamos analisar e descobrir o que são estas suposições essenciais e como necessitamos repensar estas idéias para entendermos melhor AJAX.

O navegador hospeda uma aplicação, e não conteúdo

Numa aplicação Web clássica baseada em páginas, o navegador é efetivamente um terminal burro, ou seja, ele não sabe o que o utilizador está realmente realizando em suas ações consequentes. Todas essas informações são retidas no servidor web, tipicamente na sessão do utilizador, afinal, atualmente, sessões de utilizador no lado servidor são comuns. Se a aplicação foi escrita em PHP, Plataforma Java, .NET, Ruby on Rails ou outra linguagem utilizada no desenvolvimento de aplicações para Web, a sessão no lado servidor faz parte da API padrão, assim como o controle de solicitações, respostas, e tipos de conteúdo (MIME).

Quando o utilizador entra ou de outra maneira inicia uma sessão, vários objetos são criados no servidor, representando, por exemplo, a cesta de compras e as credenciais de cliente do utilizador. Ao mesmo tempo, a página inicial é servida ao navegador, em um fluxo de marcações HTML que mistura um anúncio de apresentação padrão e dados específicos do utilizador juntos com o conteúdo, como por exemplo, uma lista de itens exibidos recentemente.

Toda vez que o utilizador interage com o sítio, um outro documento é enviado para o navegador, contendo a mesma mistura de cabeçalhos e dados. O navegador retira o documento anterior e exibe o novo, porque ele não sabe que o outro documento produz um resultado muito semelhante.

Quando o utilizador efetua a saída ou fecha o navegador, a aplicação sai e a sessão é destruída. Qualquer informação que o utilizador 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.

Neste novo cenário, quando o utilizador entra, um documento mais complexo é entregue ao navegador, uma grande proporção do qual é código JavaScript. Este documento permanecerá com o utilizador por toda a sessão, ainda que ele resolva provavelmente alterar sua aparência consideravelmente, enquanto o utilizador está interagindo com ele. Ele sabe como responder às informações inseridas pelo utilizador e é capaz de decidir se manipula a entrada do utilizador ele mesmo ou se passa uma solicitação para o servidor web (o qual tem acesso ao banco de dados do sistema e outros recursos), ou ainda, se faz uma combinação de ambos.

Ele também pode armazenar o estado ou unidade da federação, porque o documento continua persistindo sobre toda a sessão do utilizador. 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.

O servidor fornece dados, e não conteúdo

Como observamos, uma aplicação web clássica oferece a mesma mistura de alegorias, conteúdos e dados em todos os passos. Quando nosso usuário adiciona um item na cesta de compras, tudo que precisamos realmente é responder com o valor atualizado da cesta ou informar se alguma coisa deu errado.

Um carrinho de compra baseado em Ajax pode comportar-se de forma mais inteligente, por meio de remessas de solicitações assíncronas ao servidor. O cabeçalho, o histórico de navegação, e outras características do layout da página estão todas carregadas, portanto o servidor necessita enviar de volta somente os dados relevantes.

Uma aplicação Ajax poderia fazer isto de vários modos, como por exemplo, devolver um fragmento de JavaScript, um fluxo de texto simples, ou um pequeno documento XML. Nós mostraremos em detalhes as vantagens e desvantagens de cada um, mais a frente. É suficiente dizer por agora que qualquer um destes formatos será muito menor que a misturada de informações devolvida pela aplicação web clássica.

Em uma aplicação Ajax, o tráfego tem sua maior intensidade no início, com um largo e complexo cliente sendo entregue em uma única explosão, quando o usuário entra. As comunicações subsequentes com o servidor são muito mais eficientes, de qualquer forma. Para uma aplicação breve, o tráfego cumulativo pode ser menor em uma aplicação de página web convencional. Mas conforme o tamanho médio do tempo de interação aumentar, o custo de largura de banda da aplicação Ajax torna-se menor do que sua aplicação clássica equivalente.

A interação do utilizador com a aplicação pode ser flexível e contínua

Um navegador web oferece duas maneiras de enviar entradas de dados para um outro computador: com os hyperlinks e formulários HTML.

Os hyperlinks podem ser carregados com parâmetros CGI (Common Gateway Interface – Interface de Comunicação Comum) apontando para páginas dinâmicas ou servlets. Eles podem estar vinculados com imagens e folhas de estilo (CSS) para oferecer uma pequena melhoria na interface, como por exemplo, definir efeitos quando o mouse estiver sobre eles.

Os 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. Entretanto estes controles não são suficientes. Não existem controles de seleção em árvores, grades para edição, ou caixas de combinação. Os formulários, assim como os hyperlinks, apontam para URLs residentes no servidor.

Alternativamente, os hyperlinks e os controles de formulário podem apontar para funções JavaScript. Isto é uma técnica comum em páginas web para prover uma validação de formulário rudimentar em JavaScript, verificando por campos vazios, valores fora de intervalo, e assim por diante, antes de submeter os dados para o servidor. Estas funções JavaScript existem somente enquanto a própria página existe e é substituída quando a página efetuar o seu envio.

Enquanto a página está sendo enviada, o usuário aguarda a sua resposta. A página anterior pode ainda estar visível por algum tempo, e o navegador pode até permitir que o usuário clique em qualquer um dos links visíveis, mas se assim for feito, produzirá resultados imprevisíveis e até entornar em uma confusão com a sessão no servidor. O usuário está normalmente aguardando a página ser atualizada que, frequentemente, possuem quase que as mesmas informações que lhes foram apanhadas instantes atrás. Adicionando um par de calças à cesta de compras não é razoável modificar as categorias em um nível acima por “roupas masculinas”, “roupas femininas”, “infantis” e “acessórios”.

Voltemos ao exemplo do carrinho de compras novamente. Devido ao fato de que nosso carrinho de compras em Ajax pode enviar dados assíncronamente, os utilizadores podem soltar os objetos dentro dele tão rápido quanto eles podem clicar. Se o código de nosso carrinho no lado cliente for robusto, ele tratará esta tarefa facilmente, e os usuários podem continuar com o que eles estão fazendo.

É claro que não existe nenhum carrinho para colocarmos as coisas, somente um objeto em sessão no servidor. Mas 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. Troca de contextos entre a metáfora e o acesso direto ao computador é uma distração para usuários. Aguardar uma página ser atualizada levará o usuário à realidade de estar sentado em um computador por um curto tempo, e nossa implementação em Ajax evita que isto ocorra. Fazer compras é 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 de planejamento complexa, então o custo de interrupção da sequencia de trabalho em alguns poucos segundos, com uma atualização de página, é algo inviável.

A segunda vantagem de Ajax é que podemos associar eventos a um maior número de ações do usuário. Os conceitos mais sofisticados de interface com o usuário, assim como “arrastar e soltar”, se tornam praticá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 exercer 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 comunicar com o servidor em uma aplicação web clássica, necessitamos clicar em um hyperlink ou submeter um formulário, e então aguardar. No entanto, este método interrompe a interação com o usuário. Em contraste, a possibilidade de se comunicar com o servidor em resposta a um movimento ou arraste do mouse, ou até quando digitamos, habilita o servidor a trabalhar juntamente com o usuário. Google Suggest é 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.

Real codificação requer disciplina

Neste momento, as clássicas aplicações web fazem uso de JavaScript em certas ocasiões, para adicionar características avançadas e exageradas de um programa, agregando-as nas páginas. O modelo baseado em páginas previne qualquer uma destas melhorias que consista em um atraso longo demais, o qual limita as utilidades para as quais elas podem ser oferecidas. Isto fez com que JavaScript recebesse injustamente, uma reputação de algo banal – por má sorte da linguagem – e não sendo bem vista pelos desenvolvedores sérios.

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 escapes de memória. Se estivermos mirando no mercado de aplicações poderosas, então temos em vista muitas horas de intenso uso. Para atingirmos este objetivo, devemos escrever códigos de alto-desempenho, e manuteníveis, 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, de preferência, responsabilidade de uma equipe do que apenas um indivíduo, criando edições de manutenibilidade, separações de interesses, e estilos e padrões de codificação comum. Uma aplicação Ajax, portanto, é uma porção de código funcionalmente complexa que comunica eficientemente com o servidor enquanto o usuário continua com seu trabalho. Ela é claramente uma descendência da aplicação clássica baseada em páginas.

Referências

Wikipedia