Google Suggest: Não é Ajax

Como assim? Mas eu digito uma letra e aparece uma janelinha me dando sugestões em tempo de digitação!
Pois é, o Google Suggest utiliza sim requisições assíncronas mas não podemos chamar de Ajax.
O famoso Ajax ficou conhecido devido ao uso do objeto XMLHttpRequest e o nosso amigo Google não utiliza este objeto para fazer suas requisições assíncronas, ele utiliza simplesmente o fato de chamar scripts externos.

Essa é uma técnica antiga muito utilizada quando o XMLHttpRequest não era tão famoso, o pessoal já se virava com seus scripts dinâmicos e iframes.

Como funciona internamente o Google Suggest?

Na primeira letra digitada ele faz a criação dinâmica de uma tag <script> já setando seu atributo src para http://clients1.google.com.br/complete/search?hl=pt-BR&q= sendo que o parâmetro q equivale ao valor do campo de busca.

Então por exemplo, vou buscar sobre “futebol”, assim que digito a letra “f”, ele faz todo esse processo apontando para http://clients1.google.com.br/complete/search?hl=pt-BR&q=f 

Na segunda letra digitada, visto que a tag <script> já foi criada anteriormente ele simplesmente muda o atributo src agora apontando para a nova url http://clients1.google.com.br/complete/search?hl=pt-BR&q=fu

Mas como através dessa requisição aparece a lista de sugestões ?

A resposta dessa requisição é simplesmente texto puro, mas por ser chamada na tag <script> ela acaba sendo reconhecida como JavaScript e sendo executada por quem a chamou, em nosso caso a página inicial do Google.
O retorno da requisição é simplesmente isso (Um exemplo para a busca da palavra fut):

window.google.ac.h(["fut",[["futebol ao vivo","5.880.000 resultados","0"],
["futebol","39.800.000 resultados","1"]

Somente essa linha de código é responsável por popular a lista de sugestões.

Segue abaixo uma screenshot no momento da “popularização” de dados:

Por que a Google não utilizou o XMLHttpRequest? Isso foi uma boa solução?

Não é interessante para o Google Suggest controlar o retorno da requisição, saber readyState, status, nada disso é interessante visto que uma requisição é feita a cada letra digitada, então cada requisição sobrescreve a outra.

Não estamos preocupados se a requisição foi feita corretamente, ele simplesmente faz a requisição e se concluir OK, se não der tempo de completar (Isso é bem provável pois se outra letra foi digitada uma nova requisição foi feita), então ele esquece a chamada anterior e vai para a próxima, assim até o usuário “descansar” o dedo e dar tempo para a requisição ser concluída, logo depois a conclusão será mostrado para o usuário os resultados de sua busca.

Outro ponto interessante é a compatibilidade entre browsers. Navegadores muito antigos não têm suporte a XMLHttpRequest e atuais como o IE podem desabilitar essa opção, então na minha opinião foi uma ótima sacada sendo que é garantido que rodará em praticamente qualquer navegador.

Permissão negada para definir a propriedade XULElement.selectedIndex no FireFox

ou também conhecida como “‘Permission denied to set property XULElement.selectedIndex”…

Alguém já sofreu com este problema? Eu já
Esse erro do FireFox ocorre quando você tenta dar foco à um campo que possui auto-completar. Isso é muito estranho pois é um ato extremamente normal, essa “exceção” só ocorre em alguns campos e não pode ser capturada via try/catch.

Pesquisando, percebi que realmente se tratava de um bug, ele já foi postado no fórum de bugs da mozilla e já deram como resolvido, estranho pois utilizo a última versão do FF e continuo com esse erro, será mesmo que foi corrigido?

Enfim, como sempre há soluções para contornar o erro… Basta desativar o autocompletar do browser ou do campo específico utilizando o atributo autocomplete=”off”. Exemplo:

1 <input type=”text” name=”campo” autocomplete=”off” />

Infelizmente essa propriedade não é validada pela W3C, então os desenvolvedores costumam setar essa propriedade através de JavaScript.

1 objeto.setAttribute(“autocomplete“, “off“);

JavaScript: Fique atento as implementações do FireFox 3

Hoje tive um problema inesperado, a aplicação estava funcionando corretamente com FireFox 2 e para minha surpresa deu pau no FireFox 3, levei um bom tempo até descobrir que o novo FireFox implementou o método getElementsByClassName() cujo eu também já havia “implementado”, logo começaram os conflitos entre os dois métodos.
Então fica a dica para que conheçam as novas implementações do FireFox e certifiquem-se que sua aplicação não terá um comportamento inesperado com essa nova atualização.

Segue estes dois links interessantes para vocês ficarem por dentro:

http://developer.mozilla.org/pt/docs/Firefox_3_para_desenvolvedores
http://developer.mozilla.org/pt/docs/Mudan%C3%A7as_no_Gecko_1.9_que_afetam_websites

JavaScript: parseInt() não é bugado

Ouço muitas pessoas dizendo que a função parseInt() é bugada, em alguns casos de conversão de números como 07 ou 08 ela não retorna o valor esperado.
Só que muita gente não sabe sobre um segundo parâmetro que a função pode receber.

sintaxe: parseInt(string, base);

Este segundo parâmetro é simplesmente a base que você converterá o número, ela pode ser decimal, octal ou hexadecimal.
Quando não especificamos este parâmetro, é assumido por padrão a base decimal (10). Exceto quando você inicia a string com 0 ou 0x que automaticamente é assumido a base octal (8 ) ou hexadecimal (16).
Esta é a causa do retorno inesperado, pois quando você converte o número 08 sem especificar a base, é assumido a base octal e nesta base este número não existe (somente de 0 a 7), assim retornando o valor inesperado 0.

A forma correta, forçando a conversão na base decimal:

1 parseInt(“08“, 10); // retorna 8

Então por segurança, especifique sempre a base para qual deseja converter, ainda mais quando for um valor dinâmico.