Para evitar que o caos venha a este mundo, surge outra palavrinha: Hijax. Mas primeiro vamos voltar a algumas premissas do desenvolvimento web: aprimoramento progressivo (progressive enhancement) e degradação elegante (graceful degradation), e me desculpem se errei a tradução dos termos…

Aprimoramento Progressivo – Primeiro o Conteúdo

Ninguém começa (ou pelo menos não deveria começar) a desenvolver uma aplicação primeiro pela camada de comportamento, isso vai completamente contra a filosofia de desenvolvimento em camadas (primeiro o conteúdo, depois a apresentação e, por último, o comportamento).

A idéia é começar o desenvolvimento de baixo. Em outras palavras, desenvolva da maneira antiga, usando links como sempre se usou desde que a Internet é Internet, devolvendo páginas inteiras como resposta. Depois, somente depois, comece a adicionar funcionalidades que melhorem a experiência do usuário (nada de frescuras que o usuário só vai achar bonito, pra que reinventar o link?).

Degradação Elegante – Útil sem perder a elegância

“Degradação elegante” significa perder alguns recursos sem perder suas funcionalidades. Pode-se perder algumas animações e outros fru-frus, mas perder acesso ao conteúdo é inadmissível. CSS não é tão importante quanto as informações que queremos mostrar. Nunca ouviu a frase “mais ajuda quem não atrapalha”? A idéia é a mesma.

O desenvolvimento progressivo e em camadas é o caminho mais rápido para a degradação elegante. Mesmo utilizando Ajax, o conteúdo ainda deve continuar acessível através de um link comum. É aí onde Hijax entra.

Hijax – Seqüestrando os Links

O próprio termo explica bem o uso da técnica. Hijax, do inglês hijack (“seqüestrar”), quer dizer seqüestrar os links comuns, e transformá-los em links Ajax. Simples assim.

“Simples assim”? Bem, nem tanto, eu confesso. Seus scripts server-side precisam estar preparados para decidir se enviam o “pacote completo” ou a “versão básica” da página, se for uma requisição normal ou uma requisição assíncrona, respectivamente. Uma breve dica: header X-Requested-With. Duas versões do site? Nunca mais, isso morreu junto com o Netscape, há muito tempo.

Vale lembrar que somente o uso de Hijax não faz uma aplicação completamente acessível, usável e rica. Há muito mais a se pensar. Já falei sobre alguns aspectos para uma boa aplicação Ajax, mas tenho absoluta certeza que não passei nem perto de tudo que é necessário. Mas tudo isso já é uma boa base a ser levada em consideração, e com isso já é possível criar algo melhor que muita coisa que existe por aí, tenha certeza. E você, tem feito seu dever de casa e seguido princípios para tornar sua aplicação disponível a todos?

Posts Relacionados

• Ajax vs. Acessibilidade
• Ajax vs. Moda vs. Performance
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax
• Ajax com a Mootools

Já havia tempo que eu queria escrever esse script, mas a coragem faltava, até que ele me foi necessário. Como uso Mootools, não faria sentido usar funções autônomas, desperdiçando código. Então tomei coragem e fiz. Pronto, nem doeu…

O Código

Meu objetivo, nesse post, não é explicar a lógica por trás do script (farei isso em breve), mas sim deixar o código pronto, e explicar seu uso.

Antes de tudo, você precisará da Mootools com os módulos necessários, o que suponho que você já possua. Depois, faça o download do Async Upload. Agora, basta incluir os dois scripts em sua página.

<script type="text/javascript" src="mootools.js"></script>
<script type="text/javascript" src="asyncUpload.js"></script>

Utilização

Como não podia deixar de ser, o script funciona na submissão de um formulário. Ele a intercepta e a envia para um iframe escondido. Pra que tudo isso funcione, temos que definir isso no onSubmit de nosso formulário:

$(window).addEvent("load", function() { // quando terminar de carregar...
  $("seu-formulario").addEvent("submit", function() { // e o nosso formulário for enviado...
    this.upload() // fazemos nosso upload, parecido (mas não é) com Ajax
  })
}

E cadê a URL?

Como a Mootools nos dá muitas opções para trabalhar com DOM, não precisamos definir a URL no script. Essa URL vai ser retirada do próprio formulário, no action:

<form action="http://sua-url-para-envio/upload.php" id="seu-formulario">
  <input type="file" name="fileToUpload" id="fileToUpload" />
</form>

Elemento de Retorno

Muito melhor do que elementos de retorno, podemos definir uma função para tratar o retorno do upload. Para isso, passamos um parâmetro para a função:

$(window).addEvent("load", function() {
  $("seu-formulario").addEvent("submit", function() {
    this.upload({
      "onComplete": function(response) {
        $("elemento_de_retorno").setHTML(response)
      }
    })
  })
}

Com o código acima, o resultado da requisição iria para uma div (ou algum outro elemento) de id “elemento_de_retorno”. É claro, pode-se fazer muito mais, mas fica a seu cargo decidir…

Recebendo o Arquivo

Apesar de assíncrono (ou Ajax disfarçado), esse upload funciona como um upload comum. No PHP, por exemplo, podemos receber o arquivo assim:

move_uploaded_file($_FILES["fileToUpload"]["tmp_name"], "nome_do_arquivo.txt");

Exemplo e Download

Caso queira dar uma olhada, deixei um exemplo na página de downloads. Faça upload de um arquivo qualquer e veja o funcionamento! Caso deseje saber a lógica por trás de tudo isso, aguarde os próximos posts. Até mais!

Posts Relacionados

• Ajax com a Mootools
• Mootools – Eventos
• Mootools – Chain
• Mootools – Classes
• Mootools – Menu Sanfona

O site é focado em “ler sobre código, ler código e colaborar”, segundo o próprio Élcio. Não há muitos posts até o momento, mas o que já foi postado, tanto pelo Élcio quanto por outros colaboradores, é um conteúdo selecionado, e de boa qualidade.

Gostei muito da política do site, bastante rígida quanto à seleção de conteúdo. Teremos uma boa referência se ela for cumprida. O cadastro e postagem são abertos a qualquer um, basta enviar bom conteúdo.

Já assinei o feed e me inscrevi. Falta acertar todos os dados do cadastro, e logo estarei postando algum conteúdo, talvez até exclusivo (se me vier alguma idéia). Se quiser, também sinta-se livre para cadastrar-se e começar a postar.

Posts Relacionados

• Cliente x Seu Ego
• O que você faz em 4Kb?
• Back Button Improved!
• Ajax vs. Acessibilidade
• Ativando o Botão Voltar

Já temos a versão 1.2, então hora de atualizar!

Motools é uma biblioteca JavaScript orientada a objetos, muito modular, compacta e, na minha opinião, muito simples de usar (não tanto quanto a jQuery, foi por isso que gostei). Nesse post vou explicar como fazer as requisições assíncronas, vulgo Ajax.

Fazendo o Download

Vá em http://mootools.net, e faça o download da biblioteca. Escolha os módulos que achar necessário para usos futuros, mas inclua os seguintes: Core, Function, Array, String, Element e Ajax (sério?). Também escolha a compressão que quiser.

Feito isso, crie uma nova página, e inclua o script.

Uma Requisição Simples

Vamos fazer uma simples requisição, sem retorno algum, bastando informar ao servidor que alguma coisa aconteceu. A base para o uso de Ajax é a classe Ajax (isso mesmo, é assim que os construtores são chamados aqui, por serem baseados em um construtor Class, da própria biblioteca). Ela cria a requisição, mas não a executa. Essa parte fica a cargo do método request. Vamos ao código:

var options = { "method": "get" };
var ajaxReq = new Ajax("http://localhost/informa_servidor", options).request();

A classe possui apenas dois parâmetros que podem ser passados: url (String) e options (Object). Vamos ver todas mais adiante. Setei apenas "method", pois o método padrão na biblioteca é POST. Um bug que encontrei: se você definer o método como “GET” em vez de “get”, a biblioteca tratará como sendo POST. Ou seja, use sempre letras minúsculas.

Atualizando um Objeto

Mais uma grande facilidade da Mootools (não que as outras também não tenham): não precisamos, necessariamente, criar uma função para ser executada quando a requisição for completada, podemos apenas definir um objeto a ser atualizado. Isso pode ser feito através da opção update (String ou Object). Mais um código:

var options = { "method": "get", "update": "elementoPraAtualizar" };
var ajaxReq = new Ajax("http://localhost/retorna_resposta", options);

Essa seria uma maneira de retornar uma resposta “estática” do servidor, já que não enviamos nenhum dado junto com a requisição. Aí entra a opção data (String, nesse caso), que levará a query string juntamente com a requisição, assim: “parametro=valor&outro=valor”.

A opção data, além de uma query string, pode ser um objeto ou um elemento <form>. A biblioteca se encarrega de transforma-los em query string, seja para envio pelo método GET ou POST. Legal, né? Outro exemplo:

var queryString = { "id": userId, "action": "getName" };
var options = { "method": "get", "update": "algumElemento", "data": queryString };
var ajaxReq = new Ajax("http://localhost/envia_query_string", options);

Função onComplete

Muitas vezes não se torna necessário tratar a resposta da requisição, bastando passa-la diretamente para um elemento. A diferença é quando os dados devem ser analisados, testados, interpretados ou qualquer coisa do gênero, ou seja, precisamos de uma função pra ser executada no final da requisição. A Mootools também permite isso através da opção onComplete. Aí fica a nosso cargo implementar toda a complexidade necessária na função. Código de novo:

var options = { "method": "get", "onComplete": onComplete };
var ajaxReq = new Ajax("http://localhost/requer_tratamento", options);
var onComplete = function(text) {
  var returnText = text.treatRequest();
  $("placeholder").empty().setHTML(returnText);
  applicationStatus = 0;
}

Como podemos ver, temos todo o controle de volta quando precisamos. Seria melhor ainda se pudéssemos ter controle sobre o XML que é enviado… Que bom, pois podemos ter controle sobre ele. Para a função do onComplete, são passados dois parâmetros: o texto e o XML. Muito bom, não?

Enviando um Formulário

Essa também é ótima. Podemos enviar um formulário inteiro com apenas um comando, que é uma extensão da classe Element disponibilizada pelo módulo Ajax. Através da função $, obtemos o formulário, e pelo método send enviamos a requisição via POST.

var formReq = $("meuForm").send();

O método send possui apenas o parâmetro options, sem URL (ela é retirada do action do formulário). As opções podem ser as mesmas de Ajax.request.

Interpretando Scripts

Todo mundo sabe que às vezes é necessário interpretar toda ou uma parte da requisição, enviada como JavaScript. A Mootools disponibiliza mais duas opções para esses casos: evalScripts e evalResponse (ambos Boolean).

Através de evalScripts, a biblioteca interpreta todos os scripts da requisição que estiverem entre as tags <script>. Caso o header recebido seja “text/javascript” ou “text/ecmascript”, toda a requisição é interpretada.

Já a opção evalResponse é mais generalista. Mesmo que seu header seja “text/html”, “text/xml” ou qualquer outra coisa, toda a requisição será interpretada. Não interessa o tipo de conteúdo. Parece ambíguo, mas as duas opções têm seu uso real.

Lembrando: as duas opções interpretam os scripts no escopo global.

Recebendo os Dados

Como sei que muita gente tem problemas na hora de receber os dados no lado do servidor, no caso do método POST, veja como receber os dados pelo PHP, de maneira simples e rápida.

Quanto à biblioteca, tem alguns pequenos defeitos. Aquele bug do “GET” que eu falei acima, a falta de um controle sobre os stateChanges, que foi retirado nessa versão, enfim. Mas isso não torna a biblioteca menos útil.

E vou ficando por aqui. Até!

Posts Relacionados

• Mootools – Options
• Ajax sem o X
• Mootools – Eventos
• Ajax: Requisições HEAD
• Fila de Requisições em Ajax

Quando fazemos a navegação via JavaScript (leia-se também Ajax), geralmente não temos controle sobre quem navega em nossa página. Tudo que temos é o log do servidor. Isso nem chega perto das ferramentas de estatísca que temos por aí, e muitas são de graça. Tudo acontece porque essas ferramentas funcionam, geralmente, através de JavaScript, que envia os dados para processamento e armazenamento. Como a navegação via JavaScript não nos dá o luxo de um reload, esse código não é executado, fazendo com que somente as visitas à pagina raiz sejam contadas.

Uma das ferramentas que permite a análise das estatísticas para navegação via JavaScript é o Google Analytics. Poderíamos utilizar o Site Overlay, que mostra as estatísticas de clique em determinadas áreas do site, mas ele não permite que cruzemos as informações. A idéia então é passar as informações para o Top Content, através da função urchinTracker, com um truque simples. Observe o código abaixo:

<a href="http://juliogreff.net/" onclick="urchinTracker('track/home')">JulioGreff</a>

O evento onclick do link acima dispara a função urchinTracker, que irá interpretar o parâmetro passado como um pageview. Aquele parâmetro será equivalente a uma URL, e você poderá filtrar os dados e cruza-los no Analytics.

O esquema é basicamente esse. Podemos adicionar a função urchinTracker não somente em links, e não somente em onclicks, mas em qualquer coisa relevante você queira monitorar e analisar mais tarde. Até aqui não há nada que quem leu documentação do Analytics não saiba. A parte legal começa agora.

Primeiramente, não devemos misturar marcação com script, conteúdo com comportamento. Ou seja, sem onclicks. Isso só nos deixa uma opção: a função mágica, addEvent:

var addEvent = function(obj, evType, fn, arg){
  if (obj.addEventListener){
    obj.addEventListener(evType, fn, true)}
  if (obj.attachEvent){
    obj.attachEvent("on"+evType, fn)}
}

Essa é a “versão básica”. Se você tem algo mais completo, melhor. Ela não é o foco do post. Para não ter que escrever muito código, eu optei pela seguinte técnica: adicionar o tracker para todos os elementos que tiverem uma determinada classe CSS, e ela seria usada como label também. Novamente, mais uma função utilitária:

var getElementsByClassName = function(className) {
  var elements = document.getElementsByTagName("*"), array = [];
  for(var i = 0; i < elements.length; i++) {
    if(elements[i].className.search(className) > -1) array.push(elements[i]);
  }
  return array;
}

Essa é a “versão pré-básica alfa”. É altamente recomendável que você use uma função decente em um ambiente real, já que getElementsByClassName("track") retornaria tanto a classe “track” quanto “tracker”, quanto “—track—”, enfim.

A função que fará o serviço sujo é Track, em versão de testes, embora utilizável. Ela pega todos os elementos com a classe “track”, e passa as próximas classes como parâmetro para o Analytics, no evento onclick. A função é a seguinte:

var Track = function() {
  // Pega todos elementos com classe "track"
  var elements = getElementsByClassName("track");
  for(var i = 0; i < elements.length; i++) {
    // Pra cada um deles adiciona o "onclick"
    addEvent(elements[i], "click", function() {
	  // Aqui uso o nome da classe como label pro Analytics
	  urchinTracker(elements[i].className.split(" ")[1].replace(/-/g, "/");
	});
  }
}
// Quando a janela carregar, "trackeio" os elementos
addEvent(window, "load", Track);

A menos que você queira algo mais específico, não é necessário modificar o código. Você só terá que modificar os elementos que você deseja monitorar, adicionando a classe “track $”, onde $ é o label que você deseja que o elemento tenha. Os traços “-” serão convertidos para barras.

Veja um exemplo, retirado do novo tema do blog, no formulário de busca:

<input type="submit" class="track geral-busca" value="Buscar" />

Você pode me perguntar: “E minhas classes declaradas no CSS?”. No meu CSS, apenas adicionei uma regra para “geral-busca”, como se fosse um ID, mas modifiquei o código para enviar ao Analytics apenas a segunda classe (“geral-busca”, no meu caso), sendo que as seguintes são completamente ignoradas, e a primeira serve apenas para “seleção” pelo script.

Agora vá para o Analytics. No seu Dashboard, clique em Content > Top Content. Ali você terá todas as URLs de seu site monitoradas pelo Analytics (as que tiveram visitas).

Assim como “/url/qualquer”, seus labels “artificiais” também estarão ali (dentro de 48 horas, às vezes menos). Nessa tela, você pode adicionar um filtro para mostrar apenas os labels que você criou, e então analisar os dados. Para isso, use o campo “Find URL”.

Agora só temos que cruzar os dados. Para isso, apenas clique no label, e na página que abrirá, escolha os dados que você deseja cruzar no campo “Segment”.

Como não sou nenhum mestre do marketing, essa parte ficará com você. Pra complementar o texto, eu recomendo que você leia os seguintes textos, escritos pelo Henrique, do Revolução Etc:

• Estratégia de métricas parte 1: Métricas para ProBloggers
• Estratégia de métricas parte 2: Google Analytics e a Função urchinTracker

Escrevi esse post me baseando na parte 2, atualizando para a nova interface do Analytics, e adicionando o script. Considero um erro encher o site de onclicks, principalmente vindo do Henrique, que preza tanto pela separação Conteúdo-Estilo-Comportamento. Fui!

Posts Relacionados

• Histórico para Navegação via JavaScript
• Botão Voltar para IE
• Utilizando o Método POST em Ajax
• JavaScript Object Notation
• ResponseXML

Não que essa idéia fosse “a aplicação ajax perfeita”, mas sim a ideal. Demoraria muito a ser feita, mas eu consideraria uma obra de arte.

Padronização

Essa parte é a parte fácil, que todo mundo sempre deveria se dar ao trabalho de fazer: manter seu trabalho dentro dos web standards.

Validar sua marcação, seus CSSs, isso todo mundo faz (ou deveria). Mas às vezes um certo item é deixado de lado: seus XMLs, que não causariam muito problema, a não ser um XML em especial: os feeds. Ou seja, valide tudo que possa ser validado.

Manutenção

Código bom é código comentado. Disso ninguém discorda. Sempre comente seus códigos, tanto para seu uso em futuras manutenções e atualizaçãoes, quanto para seus visitantes que querem descobrir o segredo daquela técnica inovadora que você implementou. JavaScript ninguém esconde, e uma técnica nova deveria poder chegar a todos que quisessem, mesmo que seja investigando seu código. Melhor ainda se ele estiver comentado, mesmo que seja somente em partes mais obscuras.

E o tamanho do código não aumentaria? Sim, mas você só precisará comentar partes essenciais, aquelas mais complicadas que você sabe que irá esquecer com o tempo. Além do mais, se você esquecer de seu código, perderá muito tempo até lembrar o que cada parte faz.

Compatibilidade

Outra parte facílima, mas indispensável. Se tudo for seguido, nem tanto, mas ainda assim se torna muito mais agradável usar uma aplicação que funcione como deveria funcionar.

Com todas as opções de browsers existentes hoje, sempre haverá aquele que terá problemas (geralmente o azulzinho que todo mundo já conhece). Mas existem maneiras de amenizar o problema. Isso não só com Ajax, mas qualquer “defeito” de JavaScript e CSS que possa atrapalhar a experiência do usuário.

Essa parte pode, sem problemas, ser deixada para os frameworks já existentes, que fazem seu trabalho muito bem. A compatibilidade vem sendo muito focada por essas bibliotecas, facilitando, e muito, seu trabalho.

Controle de readyStates

Agora começa a parte divertida. Tudo que está logo acima qualquer um faz. Vamos começar adicionando nossos diferenciais.

Geralmente, costuma-se cuidar de apenas dois readyStates: 1 e 4 (aberto e carregado), que resultam no clássico “Carregando…” e a requisição completa. Não que seja necessário, mas um controle completo de estados poderia ser bom.

O usuário saber que sua requisição está sendo processada ajuda, já que não pensaria que a requisição travou (isso acontece bastante quando a requisição demora demais).

Coloquei os readyStates, o que significam e uma sugestão para o texto de carregamento. Os readyStates 0 e 4 não precisam disso, já que 0 não tem muito uso, e 4 terá sua própria função.

• Não Inicializado (0)
• Aberto (1): “Abrindo Requisição” ou “Iniciando Requisição”
• Enviado (2): “Enviando Dados”
• Recebendo (3): “Carregando” ou “Recebendo Dados”
• Completo (4)

Não que seja necessário, mas também seria válido cuidar dos status da requisição também, pelo menos 200 (OK), 404, 500, e os outros erros mais comuns.

Histórico

Esse é o maior problema das aplicações Ajax. Já faz tempo que as primeiras soluções para histórico apareceram, e outras melhoradas, e ainda há centenas de aplicações que não se dão ao trabalho de implementar qualquer das soluções.

O histórico sempre deve ser implementado, mesmo que sua aplicação não queira dominar o mundo.

Cache

O cache, considerado uma praga por muitos, pode ser de uma grande ajuda para sua aplicação. Sempre que se faz uma requisição estática (que não muda em pouco tempo), deve-se usar o cache, pois quando refizermos essa requisição, ela terminará mais rápido.

Além do mais, usando o histórico, podemos guardar requisições “cacheadas” no próprio JavaScript. Assim, mais rápido ainda.

É claro que, em requisições dinâmicas, não devemos usar essa técnica. Ela pode prejudicar o usuário, pois não há maneira de atualizar a página através do F5.

Filas de Requisição

Todos sabem que se quando uma requisição estiver em andamento, e outra for iniciada, a primeira será cancelada.

Assim como o histórico, já existem milhares de soluções diferentes para fila de requisições. Esse recurso deve também ser usado sempre que possível (ou seja, sempre). Isso pode evitar aborrecimentos ao usuário.

Inobstrusividade

Essa é a questão mais polêmica. Sua aplicação não deve usar JavaScript obstrusivo (ou usar o menos possível), fazendo-a de maneira que funcione corretamente em qualquer browser.

E o Ajax sem JavaScript, como fica? Também tive idéias mirabolantes quanto a isso. Você deve usar o mesmo script server-side tanto para requisições assíncronas (Ajax) quanto para as síncronas (me refiro àquelas via browser). Para isso, usamos aquele header X-Requested-With, que seu server-side deve identificar.

Dessa maneira, não “trancamos” o conteúdo nem ao usuário nem aos buscadores e afins. Benefícios ao usuário e a você (e ao seu bolso, se for o caso).

Lembre-se de tornar o conteúdo Ajax-less atrativo aos olhos do usuário também, usando o mesmo layout do resto da aplicação (ou a mesma estrutura, caso seja XML).

Desempenho

O desempenho é outra característica muito essencial. Em tráfego de dados muito grande, devemos tomar cuidado com o JavaScript. Muito XML gera muitas chamadas ao DOM, e isso leva tempo. Aí o JSON entra em cena.

O Profiler do Firebug pode ser muito útil, já que ele monitora o tempo de execução da sua aplicação e das requisições que ela faz.

Bem, é isso. Quem sabe um dia veremos uma aplicação destas. Estou trabalhando em uma função que faça boa parte disso, espero que consiga terminar. Fui!

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• Fila de Requisições em Ajax
• Ajax vs. Moda vs. Performance
• Ajax: Requisições HEAD

Vamos resolver o problema por partes, na seguinte ordem:

• Bookmarking
• Histórico
• Correções para o IE
• Aperfeiçoamentos
• Código Completo e Uso

Vale lembrar também que estou escrevendo códigos para cuidar do histórico para JavaScript, e não só Ajax (aliás, todas as soluções anteriores faziam isso, mas pouca gente se tocou).

Código Base

Usaremos a seguinte página-base para testarmos nosso script:

<html>
<head>
<title>BackButton Fixes</title>
<script>
var appHash = ""; // Não se preocupe com essa linha agora...
</script>
</head>
<body>
<select id="select">
<option value="option-0">-- Change --</option>
<option value="option-1">Option 1</option>
<option value="option-2">Option 2</option>
</select>
</body>
</html>

Como testaremos a navegação somente com JavaScript, não precisaremos fazer qualquer requisição Ajax. Portanto, não precisaremos de uma função para tal.

Bookmarking

Como na navegação via JavaScript não mudamos a URL, não podemos fazer bookmarking, já que a aplicação, sempre que acessada, estará no estado inicial. A única maneira de permitir o bookmarking seria mudando a URL.

Como sempre estaremos na mesma página, acrescentaremos apenas um fragmento após o nome do arquivo. Poderíamos optar pelas query strings (file.ext?param=value), mas elas atualizariam a página quando fossem mudadas. Então optaremos pelos hashes (file.ext#hash), que não atualizam a página e podem ser mudados à vontade.

Primeiramente, quando a página é carregada, precisamos verificar se houve bookmarking:

function initialize() {
  var browserHash = window.location.hash.substring(1); // Hash da barra de navegação
  browserHash = (!browserHash) ? 0 : browserHash; // Hash padrão
  $("select").selectedIndex = browserHash;
}

Não se esqueça de modificar a tag body para <body onload="initialize()"> (nos preocuparemos com obstrusão depois), e de criar a função $() para pegar elementos pela ID.

Se especificarmos um hash “1″ ou “2″, nosso select mudará quando atualizarmos a página, ele não mudará automaticamente. Mas já temos nosso bookmarking inicial.

Por enquanto, quando mudamos nosso select, a URL não muda. Isso significa que nosso usuário terá que adivinhar qual hash deverá usar, o que não é bom. Precisamos de uma função que mude o hash do navegador quando mudarmos as opções do select:

function makeBookmark() {
  window.location.hash = "#" + $("select").selectedIndex; // Muda o hash da página
}

E também devemos modificar nosso select para <select id="select" onchange="makeBookmark()">. Agora, toda vez que trocamos as opções do select, o hash do navegador muda para podermos fazer o bookmark mais tarde.

Até o presente momento, tudo funcionando no IE, no FF e no Opera. Note que no FF e Opera o histórico já é ativado, embora não faça efeito.

Histórico

Atualmente, os browsers não disparam evento algum quando voltamos ou avançamos no histórico. Sendo assim, não existe nenhuma maneira “automática” que nos ajude a verificar quando navegarmos pelo histórico.

Para fazer a verificação, executamos uma função em um curto intervalo de tempo. Essa função verifica se o hash do browser se refere ao estado da aplicação. Se for falso, faz as modificações necessárias.

Vamos começar fazendo as alterações necessárias para a função initialize:

function initialize() {
  handleHistory(); // Verificação inicial
  window.setInterval(handleHistory, 100); // Intervalo para verificação
}

Essa é a função que faz a verificação inicial e “agenda” as próximas, a cada 100 milissegundos. A função que faz a verificação é a seguinte:

function handleHistory() {
  if(window.location.hash != appHash) { // Verificação de Estado
    appHash = window.location.hash; // Trocamos o estado da aplicação
    $("select").selectedIndex = window.location.hash.substring(1); // Trocamos a opção selecionada
  }
}

Ela compara o hash da aplicação (que é o appHash, variável global lá do início do nosso script) com o hash do browser. Se forem diferentes, faremos as adaptações, em nosso caso seria a mudança das opções do select.

Outra modificação necessária em nosso script será a função makeBookmark, que agora se chamará makeHistory:

function makeHistory(newHash) {
  window.location.hash = "#" + newHash;
  appHash = newHash;
}

Ela será executada toda vez que mudarmos as opções do select. O select também deverá ser mudado para <select id="select" onchange="makeHistory(this.selectedIndex)">.

Note que temos alguns problemas: quando no estado inicial, não temos diferença entre appHash e o hash do browser, fazendo com que nada aconteça (causa problemas com o uso de Ajax), e ainda não temos o funcionamento desejado nem no IE nem no Opera.

Correções para o IE

O IE sempre foi do contra, e ele não abriu excessão para nossa técnica anterior. Quando trocamos o hash da página, o IE não ativa o histórico, e não há maneira de contornar isso sem a gambiarra. Essa gambiarra seria o uso de um iframe escondido, do qual falaremos daqui a pouco.

Como você já deve ter entendido o espírito da coisa, vou postar o código inteiro, e vou explicando as linhas que forem necessárias, até porque alguém pode ter se perdido.

var appHash = "";
var isIe = (navigator.userAgent.toLowerCase().indexOf("msie") > -1) ? true : false;
function $(id) { return document.getElementById(id); }
function makeHistory(newHash) {
  if(isIe === true)
    $("control-iframe").setAttribute("src", "control.htm?id=" + newHash);
  window.location.hash = "#" + newHash;
  appHash = newHash;
}
function handleHistory() {
  var browserHash = (hash = window.location.hash) ? hash : "#" + 1;
  if(browserHash != appHash) {
    appHash = browserHash;
    $("select").selectedIndex = browserHash.substring(1);
  }
}
function createIFrame() {
  var iFrame = document.createElement("iframe");
  iFrame.setAttribute("src", "control.htm?id=1");
  iFrame.setAttribute("id", "control-iframe");
  iFrame.style.display = "none";
  document.body.appendChild(iFrame);
}
function initialize() {
  if(isIe === true)
    createIFrame();
  handleHistory();
  window.setInterval(handleHistory, 100);
}

Vamos pela ordem. Na função initialize, criamos um iframe escondido se o browser for o IE (definido pela variável isIe, lá no começo), através da função createIFrame, sem mistério.

Na função makeHistory, trocamos a URL do iframe (se for o caso), forçando sua atualização (veremos porque mais tarde).

No iframe, temos o seguinte código:

<html><head><script type="text/javascript">
frameUrl = window.location.search.substring(4);
parentHash = (typeof(hash = parent.location.hash.substring(1)) != "undefined" ? hash : "");
if(frameUrl != "")
  parent.location.hash = frameUrl;
</script></head><body></body></html>

Toda vez que o iframe é atualizado (seja pelo usuário ou pela navegação no histórico), ele muda o hash da página pai, nos permitindo fazer a verificação de estados.

Também fiz uma pequena modificação: estado inicial (caso não haja um hash) para o FF/Opera. Na parte do IE já fiz direto.

Aperfeiçoamentos

Para facilitar o uso, e por causa de alguns bugs existentes, fiz algumas modificações no código ao longo do tempo. Não irei explica-las agora, isso fica para uma outra oportunidade.

O código completo do script, corrigido e atualizado, é esse:

var appHash = "";
var appIndex = "";
var appDefault = "home";
var appFunction = function(){};
var isIe = (navigator.userAgent.toLowerCase().indexOf("msie") > -1) ? true : false;
function $(id) { return document.getElementById(id); }
function makeHistory(newHash) {
  if(isIe === true)
    $("control-iframe").setAttribute("src", "control.htm?id=" + newHash);
  else if(newHash != appIndex)
    window.location.hash = newHash;
  else
    go2index();
}
function handleHistory() {
  var browserHash = (hash = window.location.href.split("#")[1]) ? hash : "";
  if(browserHash != appHash) {
    if(browserHash != "") {
      appFunction(browserHash);
      appHash = browserHash;
      makeHistory(browserHash);
	}
	else {
	  clearInterval(checkInterval);
	  window.location.hash = appHash;
	  makeHistory(appIndex);
	}
  }
}
function createIFrame() {
  var iFrame = document.createElement("iframe");
  iFrame.setAttribute("src", "control.htm?id=" + (hash = window.location.href.split("#")[1]) ? hash : appDefault);
  iFrame.setAttribute("id", "control-iframe");
  iFrame.style.display = "none";
  document.body.appendChild(iFrame);
}
function initialize() {
  if(isIe === true)
    createIFrame();
  checkBookmark();
  checkInterval = setInterval(handleHistory, 100);
}
function checkBookmark() {
  var browserHash = (hash = window.location.href.split("#")[1]) ? hash : "";
  window.location.hash = (browserHash == "") ? appDefault : browserHash;
}
function go2index() {
  window.location = window.location.href.split("#")[0] + "#";
  window.location.reload();
}
function goTo(strUrl) {
	window.location.hash = strUrl;
	appFunction(strUrl);
}

E o código do iframe control.htm é:

<html><head><script type="text/javascript">
frameUrl = window.location.search.substring(4);
parentHash = (typeof(hash = parent.location.href.split("#")[1]) != "undefined" ? hash : "");
if(parentHash != "" && frameUrl == parent.window.appIndex)
  parent.window.go2Index();
else if(frameUrl != "" && frameUrl != parent.window.appIndex)
  parent.location.hash = frameUrl;
</script></head><body></body></html>

Pra usar a função, você faz sua página normalmente. Você precisará criar um arquivo com todo o script acima, e inclui-lo em sua página. Você também precisará criar o arquivo control.htm, o nosso iframe.

No script, você poderá mudar as variáveis appDefault (hash inicial), appIndex (hash que deve atualizar a página) e appFunction (função que faz a navegação). Para executar sua função de navegação, chame a função makeHistory, passando a query string como parâmetro.

Simples, não? Não, mas é fácil de usar. Dúvidas, bugs, sugestões, qualquer coisa que possa ajudar, é só comentar!

Créditos

Não criei tudo isso do nada, me baseei em algumas idéias já existentes. As principais foram de Mike Stenhouse (idéia original), Bernardo Rufino (aperfeiçoamentos), Dekassegui (correções e personalizaçãoes), e um pouco da minha idéia quase-original também (que não me lembro o nome do sujeito que tinha postado um rascunho em um fórum por aí).

Posts Relacionados

• Estatísticas para Navegação via JavaScript
• Botão Voltar para IE
• Ativando o Botão Voltar
• innerOptions
• Back Button Improved!

Vamos à uma discussão rapidinha. Pense: vale a pena escrever uma montanha de código JavaScript, correndo o risco de ficar completamente inacessível para alguns browsers, quebrar a cabeça, fazer algo bonitinho que demora o dobro pra carregar, sabendo que você podia escrever uma (uma só, nada mais, sem exagero) única linha? É o caso do pessoal que faz todos os links usando Ajax.

E não é só isso. Há muita coisa que poderia ser evitada. Carregar páginas quase inteiras, pequenos textos estáticos (babem…), outras coisinhas irritantes que pulam na tela… Quer que eu prove que não melhora a performance? XML HTTP Performance and Caching. Creio que posso te convencer.

Descartando a acessibilidade por enquanto. Um site que use Ajax, pra ser mais útil e mais rápido, precisa de muito planejamento. Um ótimo exemplo de planejamento é o Gmail e Google Reader. Inclua a acessibilidade: ainda temos o Google na frente (Gmail sem Ajax também existe). Uma boa discussão sobre isso também rolou lá no Ajax Online.

Apesar de tudo, ainda acredito que já evoluímos muito, e estamos evoluindo. O Ajax no Brasil já amadureceu bastante (até o Ajax Online abandonou a versão 100% Ajax, evolução). Ainda temos muito a progredir, e vai demorar, eu sei, mas não podemos parar. Graças a muita gente já temos trabalhos bons. Agora queremos trabalhos ótimos, basta amadurecer a idéia.

Esta é a minha opinião, não tomem como certa. Apenas pense sobre isso, concorde ou não. Até!

Também já havia falado sobre essas algumas questões relacionadas a Ajax em Ajax vs. Acessibilidade. Também falei sobre A Aplicação Ajax Perfeita, que pode colocar algumas minhocas em sua cabeça…

Posts Relacionados

• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• A Aplicação Ajax Perfeita
• Fila de Requisições em Ajax
• Ajax: Requisições HEAD

O que é uma requisição HEAD?

Em uma requisição do tipo HEAD, oição do tipo HEAD, o servidor apenas retorna as linhas de cabeçaletorna as linhas de cabeçalho (os headers) de um arquivo qualquer. Isso quer dizer que podemos descobso quer dizer que podemos descobrir o Content-Type, ou Last-Modified de um arquivo sem precisar receber todo ele.
Qual é a utilidade disso tudo? Não muita, concordo. Mas pense. Temos um arquivo extremamente grande para ser retornado. Devemos atualizar ele a um certo tempo, mas não precisamos disso se sua última modificação foi antes da primeira requisição. Fazemos uma requisição HEAD, descobrimos isso, e retornamos tudo aquilo apenas se precisarmos. Redundante, pouco prático, mas ainda assim é útil.

Fazendo a tal requisição

Para fazermos a “tal requisição”, precisamos de um objeto XMLHttpRequest já setado. Mas antes de colocar a mão na massa, veja o que pode ser o cabeçalho de um arquivo:

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Cache-Control: max-age=172800
Expires: Sat, 06 Apr 2002 11:34:01 GMT
Date: Thu, 04 Apr 2002 11:34:01 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 14 Mar 2002 12:06:30 GMT
ETag: "0a7ccac50cbc11:1aad"
Content-Length: 52282

Veja bem: você conhece (e talvez usou, em Ajax mesmo) alguns desses headers. Até creio que seja possível retorna-los mesmo em uma requisição GET ou POST, mas não vem ao caso.
Para retornarmos um header individual, utilizamos o método getResponseHeader(strName), e para retornarmos todos os headers podemos usar getAllResponseHeaders(). Um exemplo mais prático:

// Eis o mistério resolvido
xmlhttp.open("HEAD", "http://qualquer.lugar.com", false);
// Usei uma requisição síncrona, pra não precisar tratar dos readyStates
xmlhttp.send("");
alert(xmlhttp.getAllResponseHeaders());

Facinho, não? Eu disse, o difícil é achar utilidade, mas se você tem uma mente engenhosa ou estilo dominador-global-ou-genérico-maluco, você vai achar…

Posts Relacionados

• Fila de Requisições em Ajax
• Ajax sem o X
• Utilizando o Método POST em Ajax
• Ajax com a Mootools
• Ajax vs. Acessibilidade

Preparação

A fila de requisições baseia-se em uma variável (lógico). Usaremos um simples array:

var fila = new Array();

Precisaremos também de duas funções, uma que coloca a requisição na fila, e outra que executa a fila em ordem.

Colocando na Fila

Para colocarmos um item na fila, usaremos a função queueAjax, descrita abaixo.

var queueAjax = function(id, url) {
  // Usando o id, você pode colocar um carregando:
  document.getElementById(id).innerHTML = "Carregando...";
  // Adicionando nossa requisição:
  fila.push([id, url]);
  // Não tendo requisições pendentes, lançamos outra função
  if(fila.length > 1) executeQueue();
}

Analisando: colocamos id e url na fila, de uma forma ou outra. Se não houverem mais que uma requisição na fila, executamos a função executeQueue() (sem argumentos mesmo). Ela se encarregará de todo o resto.

Executando cada Requisição…

Não precisaremos executar cada requisição manualmente (lógico, a fila é pra isso). Usaremos a função executeQueue() pra isso. Neste momento, estou assumindo que você tem a variável xmlhttp configurada como um objeto XMLHttpRequest.

var executeQueue = function() {
  var current = fila.shift(); // Retiramos o primeiro membro do array
  xmlhttp.open("GET", current[1], true);
  xmlhttp.onreadystatechange = function() {
    // Aqui você cuida dos readyStates
    // Quando for 4: (não coloquei o código, poupando espaço)
    document.getElementById(current[0]).innerHTML = xmlhttp.responseText;
    // Tá pronto, e passamos ao próximo item, se houver
    if(fila.length > 0) setTimeout(executeQueue, 100);
  }
  xmlhttp.send(null);
}

Analisando de novo: fazemos nossa requisição como sempre (poupei código, também pra prevenir Ctrl + C e V). Note que tiramos o primeiro item do array, e colocamos em uma variável.
Quando a nossa requisição atual estiver prontinha, e o resultado no lugar, podemos executar a próxima (se houver), sem que precisemos fazer nada.

Usando tudo isso

Pra usar você só vai precisar chamar uma função: queueAjax(id, url), pra cada requisição que você quiser fazer. Nada mais.
Você também pode estender muito mais esse script, colocando opções, tratamento para as saídas… Dê asas a sua criatividade.

Posts Relacionados

• Ajax: Requisições HEAD
• Utilizando o Método POST em Ajax
• Ajax com a Mootools
• Ajax vs. Acessibilidade
• A Aplicação Ajax Perfeita