1
2
3
4
5
6

$.fn.extend({clickPrevented: function(fn) {
	$(this).click(function(e) {
		e.preventDefault();
		fn(e);
	});
}});

A utilização aconteceria mais ou menos assim:

1
2
3

$('#apenas_um_cara').clickPrevented(function(){
        alert('Você vai continuar nesta página após o alert.');
});

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

(function($){
	$.fn.hhSelectMaker = function(data, cfg) {
 
		var cfg = cfg || {};
		if ( !cfg.key) cfg.key = 'key';
		if ( !cfg.value) cfg.value = 'value';
		if ( !cfg.selected) cfg.selected = false;
 
		var snippet = '';
		for (var i = 0; i < data.length; i++) {
 
			snippet += "<option value='" + data[i][cfg.key]; 
 
			if (cfg.selected === data[i][cfg.key]) {
				snippet += " selected='selected' ";
			}
 
			snippet += "'>" + data[i][cfg.value] + '</option>';
		}
		return this.append(snippet);
	};
})(jQuery);

Como funciona?

Montei dois exemplos para ilustrar o funcionamento do plugin.
O plugin recebe dois argumentos. O primeiro, obrigatório, é a fonte de dados. O segundo, opcional, é a configuração da fonte de dados.

Caso somente o primeiro argumento seja passado, o plugin espera um estrutura de dados no seguinte formato:

var dados = [
    { key: 'Chave1', value: 'Valor1' },
    { key: 'Chave2', value: 'Valor2' },
    { key: 'Chave3', value: 'Valor3' }
    // etc...
];

O nome das chaves pode ser modificado utilizando-se o segundo argumento:

$('select').hhSelectMaker(dados, {
	key: 'id', value: 'nome', selected: '5'				
});

Configurando-se o plugin desta maneira a estrutura de dados esperada é a seguinte:

var dados = [
    { id: 'Chave1', nome: 'Valor1' },
    { id: 'Chave2', nome: 'Valor2' },
    { id: 'Chave3', nome: 'Valor3' }
    // etc...
];

Além disso, a chave selected permite que um determinado valor seja selecionado como padrão após o carregamento do plugin.

Ele é muito útil porque geralmente determinados objetos de uma página possuem algum tipo de relação que os agrupa. Vamos imaginar a seguinte estrutura:

1
2
3
4
5
6
7
8
9
10
11

	<ul id="menu">
	    <li><a href="#">Capítulo 1</a></li>
	    <li><a href="#">Capítulo 2</a></li>
	    <li><a href="#">Capítulo 3</a></li>
	</ul>
 
	<div id="capitulos">
	    <div>Conteúdo capítulo 1</div>
	    <div>Conteúdo capítulo 2</div>
	    <div>Conteúdo capítulo 3</div>
	</div>

Um item de menu, ao ser clicado, faz com que seu respectivo conteúdo seja mostrado na tela. Todas as divs de conteúdo estão inicialmente escondidas. Se um item de menu for clicado novamente, todas as divs são escondidas e a div de conteúdo correspondente é revelada. Uma situação muito comum, trivial e extremamente recorrente. O código abaixo implementa a situação:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

var gerenciarCapitulos = function(){
	$('#menu li a').click(function(e){
		e.preventDefault();
		var indice = $(this).index('#menu li a');
		mostrarConteudo(indice);
	});
};
 
var mostrarConteudo = function(indiceCapitulo){
	var 
	capitulos = $('#capitulos div'),
	divCapitulo = $(capitulos[indiceCapitulo]);
 
	capitulos.hide();
	divCapitulo.show();
};
 
$(function(){
	gerenciarCapitulos();
});

Index é utilizado na linha 4:

4

		var indice = $(this).index('#menu li a');

Neste caso index recebe como argumento um seletor que indica o contexto que deve ser utilizado para descobrir o índice em relação a this (ou seja, o elemento clicado). Como os items de menu estão na mesma sequência das divs de capítulos o índice acaba sendo o mesmo. O valor do índice é passado para a função mostrarConteudo que recupera do vetor capitulos a div que deve ser mostrada:

12

	divCapitulo = $(capitulos[indiceCapitulo]);

Aqui você pode encontrar o exemplo funcionando.

Um exemplo ruim que não utiliza o método index

É possível programar a mesma funcionalidade de várias outras maneiras sem a utilização de index. Antes eu contava com “ids” que tivessem números em comum. Entretanto, isso implicava em mais código html:

1
2
3
4
5
6
7
8
9
10
11

	<ul id="menu">
	    <li id="link-1"><a href="#">Capítulo 1</a></li>
	    <li id="link-2"><a href="#">Capítulo 2</a></li>
	    <li id="link-3"><a href="#">Capítulo 3</a></li>
	</ul>
 
	<div id="capitulos">
	    <div id="capitulo-1">Conteúdo capítulo 1</div>
	    <div id="capitulo-2">Conteúdo capítulo 2</div>
	    <div id="capitulo-3">Conteúdo capítulo 3</div>
	</div>

Percebam que agora todos as lis de menu e todas as divs de capítulo possuem ids. O código JavaScript correspondente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

var gerenciarCapitulos = function(){
	$('#menu li a').click(function(e){
		e.preventDefault();
		var indice = $(this).parent().attr('id').split('-')[1];
		mostrarConteudo(indice);
	});
};
 
var mostrarConteudo = function(indiceCapitulo){
	var 
	capitulos = $('#capitulos div'),
	divCapitulo = $('#capitulo-' + indiceCapitulo);
 
	capitulos.hide();
	divCapitulo.show();
};
 
$(function(){
	gerenciarCapitulos();
});

Somente as linhas 4 e 12 foram modificadas. Na linha 4 utilizamos um split para obter o índice. Na 12 um seletor é montado dinamicamente utilizando este índice. É um código fraco e pouquíssimo elegante. Exemplo ruim pode ser encontrado aqui.

O framework JavaScript do Yahoo!,YUI, sempre recomendou que seus códigos fossem carregados remotamente. Este post do Ajaxian elenca uma série de vantagens. Destaco algumas delas:

• caching é feito corretamente; desenvolvedores não precisam mais se preocupar com isso
• gzip funciona
• a CDN do Google, distribuida em vários lugares do mundo, possibilita que os arquivos hospedados estejam “próximos” do usuário
• se uma quantidade significativa de websites utilizar a mesma URL para carregar um determinado framework, quando alguém entrar no seu site pode ser que este arquivo já tenha sido carregado

Faz bastante sentido para mim. Claro que se por um acaso os servidores do Google ficarem indisponíveis, ou o serviço descontinuado, você terá graves problemas. Além disso, os mais paranóicos podem afirmar que este é apenas mais um método desenvolvido para colher informações de usuários. Mas isso com certeza não impede que as pessoas continuem utilizando Gmail ou Analytics.

Outro potencial problema é que você fica dependente de uma conexão com a internet para desenvolver. A vantagem é que a maioria dos desenvolvedores não consegue mesmo trabalhar offline. Nosso trabalho já depende demais ferramentas online para isso ser uma preocupação genuína.

Como funciona?

Existem dois jeitos de se utilizar o serviço. O primeiro, é mais “estático” e simples. O processo é igual ao que você já faz: para incluir um framework, como MooTools, Dojo, jQuery, você deve incluir script src=”" em seu html. Basta fazer com que o atributo src desta tag aponte para uma URL do serviço: http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.min.js. Este link leva diretamente para a versão minificada do jQuery 1.4 (que hoje é a mais atual).

O segundo jeito, mais “dinâmico”, consiste em incluir utilizando script src=”" o código fonte da API Ajax do Google: http://www.google.com/jsapi. Com este código disponível, você pode carregar os frameworks. Vamos incluir novamente o jQuery utilizando o método estático:

google.load("jquery", "1"); // obtém a última versão da família 1 (que hoje é a 1.4)
google.setOnLoadCallback(function() {
 
    $(function(){
        alert('Olá');
    });
 
});

A vantagem desta forma é que, com ela, você pode definir, como no exemplo acima, que quer pegar a versão mais atual do jQuery família de versão 1. É possível ser mais específico:

// obtém versão 1.3.2 (que é a última da família 1.3)
google.load("jquery", "1.3"); 
 
// obtém especificamente a versão 1.2.6 sem compressão
google.load("jquery", "1.2.6", {uncompressed:true});

É uma funcionalidade um pouco mais difícil de implementar mas sem dúvida interessante, pois permite que o seu código sempre utilize a versão mais atual de uma determinada família.

1
2
3
4
5

$('a').click(function(){
    var href = $(this).attr('href');
    window.open(href);
    return false;
});

Este exemplo em jQuery, se executado, fará com que todos os links desta página sejam abertos em uma nova guia. O return false na linha 4 serve para barrar o evento padrão do link. Se o return for omitido, o destino do link vai ser aberto em uma nova guia e também na página atual.

preventDefault: uma alternativa mais elegante

Descobri recentemente o método preventDefault que acaba sendo muito mais prático e menos sujo do que o return false:

1
2
3
4
5

$('a').click(function(event){
    event.preventDefault();
    var href = $(this).attr('href');
    window.open(href);
});

Além de fazer muito mais sentido do que o return, preventDefault pode ser colocado em qualquer parte do evento, não interrompendo o fluxo da função.

$('#post-238 h2 a').css('color','white');
 
if ($('#post-238 h2 a').text() === 'Colocando objetos jQuery em variáveis') {
    alert('Entramos na condição. Texto alterado para branco.');
}

Quando na verdade, o código abaixo é perfeitamente possível e muitíssimo mais limpo:

var conteudo = $('#post-238 h2 a');
 
conteudo.css('color','yellow');
 
if (conteudo.text() === 'Colocando objetos jQuery em variáveis') {
    alert('Entramos na condição. Texto alterado para amarelo.');
}

Vantagens

É boa prática em programação evitar a duplicação de código (no caso a string que define o seletor). Isso evita bugs e facilita o entendimento e a manutenção do código. Além disso, imagino que a performance seja maior.

Sou só eu???

Quando o Felipe Pupo começou a me ensinar MooTools, ele me mostrou que adquirir o objeto do DOM uma única vez era uma das grandes vantagens em relação ao jQuery. Sempre achei que a repetição do $ e dos seletores o tempo todo era algo realmente pouco prático. Não sei se isso é algo novo no jQuery ou se é algo que eu nunca havia reparado.

O fato é que não sou só eu que faço isso. Uma grande parte dos programadores jQuery não armazena os objetos já adquiridos em variáveis. Será que existe algum efeito colateral?

O problema da acentuação

Infelizmente o plugin é rígido ao tratar caracteres. O comportamente desejado era que os mesmos resultados fossem devolvidos digitando-se, por exemplo, “são” ou “sao” (São Paulo e outros resultados apareceriam neste caso). Isso não acontecia. Ao digitar sao, “São Paulo” não era um dos resultados. Entretanto, percebi que o plugin não diferenciava caixa alta e baixa: SÃO e são retornam o mesmo resultado.

A gambiarra

Modificar plugins é uma péssima prática por vários motivos:

• um bug pode ser introduzido (e só percebido depois)
• se uma nova versão do plugin for lançada, a modificação tem que ser refeita
• pior: a modificação pode não funcionar numa nova versão

Plugins bem feitos geralmente fornecem formas de personalização do comportamento através de objetos de configuração. Em algumas situações, como no nosso caso, isso não é possível. Vasculhei o código do plugin pelo método toLowerCase (conversão de caixa alta para caixa baixa):

177
178
179
180

if( data[i].result.toLowerCase() == q.toLowerCase() ) {
    result = data[i];
    break;
}

255
256

if (!options.matchCase)
    currentValue = currentValue.toLowerCase();

Continuei buscando e encontrei ocorrências da conversão em mais cinco ou seis lugares. Então criei um método prototype para o objeto String chamado filterData:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

String.prototype.filterData = function() { 
 
    var
    str = this.toLowerCase(),
    specialChars = [
        {val:'a', let:'áàãâä'},
	{val:'e', let:'éèêë'},
	{val:'i', let:'íìîï'},
	{val:'o', let:'óòõôö'},
	{val:'u', let:'úùûü'},
	{val:'c', let:'ç'},
    ],
    regex;
 
    for (var i in  specialChars) {
	regex = new RegExp('[' + specialChars[i].let + ']', 'g');
	str = str.replace(regex, specialChars[i].val);
	regex = null;
    }
 
    return str;
};
 
// Exemplo de uso
alert('Isto é um teste. NÃO podemos ter acentos nem CAIXA ALTA!'.filterData());

Finalmente, para encerrar a gambiarra, substitui no código do plugin todas as ocorrências de toLowerCase para filterData:

177
178
179
180

if( data[i].result.filterData() == q.filterData() ) {
    result = data[i];
    break;
}

255
256
257
258

if (!options.matchCase)
    currentValue = currentValue.filterData();
 
// e em todo o resto do plugin

E funciona! Vou tentar entrar em contato com o autor do plugin sugerindo esta funcionalidade para a próxima versão.

Observação: utilize UTF-8

Para esta modificação funcionar a página HTML deve ter o seu charset declarado como UTF-8. O charset ISO-8859-1 não funciona. Sei disso porque a página original teve que ser alterada para UTF-8. Com ISO-8859-1 buscas com acentos não retornavam resultado algum. Mistério, não tenho idéia porque isso ocorre.