Definição de AJAX

AJAX (acrônimo em língua inglesa de Asynchronous Javascript And XML) é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornar páginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. Foi inicialmente desenvolvida pelo estudioso Jessé James Garret e mais tarde por diversas associações.

Por | @oficinadanet Programação

AJAX (acrônimo em língua inglesa de Asynchronous Javascript And XML) é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornar páginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. Foi inicialmente desenvolvida pelo estudioso Jessé James Garret e mais tarde por diversas associações.

Descrição


AJAX não é somente um novo modelo, é também uma iniciativa na construção de aplicações Web mais dinâmicas e criativas. AJAX não é uma tecnologia, mas um conjunto de tecnologias conhecidas trabalhando juntas, cada uma fazendo sua parte, oferecendo novas funcionalidades. AJAX incorpora em seu modelo:
  • Apresentação baseada em padrões, usando XHTML e CSS;
  • Exposição e interação dinâmica usando o DOM;
  • Intercâmbio e manipulação de dados usando XML e XSLT;
  • Recuperação assíncrona de dados usando o objeto XMLHttpRequest e XMLHttpResponse;
  • JavaScript fazendo a junção entre os elementos.

O modelo clássico de aplicação web trabalha 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 possui muito dos sentidos técnicos, mas não faz tudo que um usuário experiente poderia fazer. Enquanto o servidor está fazendo seu trabalho, o que o usuário estará fazendo? O que é certo, esperando. E a cada etapa em uma tarefa, o usuário aguarda mais uma vez.

Obviamente, se nós estivéssemos projetando a Web a partir do zero para aplicações, não faríamos com que os usuários esperassem em vão. Uma vez que a interface está carregada, por que a interação do usuário deveria parar a cada vez que a aplicação precisasse de algo do servidor? 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. O desenvolvimento do AJAX foi muito importante para o desenvolvimento da Web 2.0 a partir de 2005, levando à Internet funções inesperadas, que passariam por ficção há pouco 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 estruturas que nós usamos, e também em nossas maneiras de pensar. Vamos fazer uma análise de alguns minutos para descobrir o que são estas suposições essenciais e como necessitamos repensar estas idéias para entendermos Ajax suficientemente. O AJAX também pode ser usado para software de modelagem 4D em HTML, Javascript, XML, DHCP, Net, Net fone e PHP editor. Ele não elabora operações em computadores mais novos, mas não há nada que um 486 não possa fazer.

O navegador hospeda uma aplicação, e não conteúdo
Numa aplicação web clássica baseada em páginas, o navegador é efectivamente um terminal burro. Ele não sabe nada sobre o que o utilizador está realmente realizando em suas ações conseqüentes. Todas essas informações são retidas no servidor web, tipicamente na sessão do utilizador. Sessões de utilizador no lado servidor são comuns atualmente. 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, porque o documento continua persistindo sobre toda a sessão do usuário. 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 subseqüentes 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 enlaces 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 facto de que nosso carrinho de compras em Ajax pode enviar dados assíncronamente, os utilizadores podem soltar os objectos 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 seqüência 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. O 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.

Fonte: Wikipédia

Mais sobre: ajax
Share Tweet
DESTAQUES
Mais compartilhados
Comentários