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 mostrar
emos 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 cum
ulativo 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 usuário 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 d
os 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 assincronamente, os usuários 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 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 ma
is 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 movim
ento 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 b
em 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 importante. 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, mas a similaridade não é mais forte do que entre um cavalinho de madeira e uma moderna bicicleta de passeio. Sustentando essas diferenças em mente nos ajudará a criar aplicações web verdadeiramente convincentes.
Ajax não é Linguagem de Progamação! :D
