E aí povo!?! Feliz 2009 para todos!
O ano passa rápido, só agora que vim postar de novo percebi que postei há quase um ano aqui no ClientSide. Bom, neste post gostaria de comentar mais uma vez sobre algumas técnicas de programação em javascript, levando carona na febre jQuery.
Para mim, o mais interessante dessas bibliotecas é como os desenvolvedores utilizam as mais variadas técnicas para resolver seus problemas. Vocês viram que saiu a versão 1.3 do jQuery?
Uma coisa que me chamou muita atenção nessa nova versão é o uso de uma técnica chamada “Feature Detecting”, que além de aumentar o desempenho ainda aumentou a gama de compatibilidade com os navegadores.
Eu não quero pegar pesado, então vou falar a grosso modo de como funciona essa técnica para que maioria ou todos possam entender.No desenvolvimento com Js, foi e ainda é muito comum o uso de browser sniffing, que é a detecção de qual navegador o usuário está usando para poder usar determinado script. Como este código.
O grande problema do uso desta técnica é que ela limita o número de browsers compatíveis com a sua aplicação, excluindo outros browsers que não entram na detecção.
Outro problema é que a cada trecho do código é necessário executar uma verificação para descobrir qual browser está sendo usado e o tamanho do código aumenta generosamente conforme a necessidade de acrescentar um novo browser compatível.
Há outras desvantagens, mas neste post não caberiam todas elas.Eu usava feature detecting mesmo sem saber que tinha este nome, meio sem querer, confesso que usava por pura preguiça, porque eu odiava aquela história de navigator.appName.
Terrível isso. A solução que eu usava e compartilho com vocês foi essa:
1
2
3
4
| function feature( support ){
for ( var x in support )
feature[x] = support[x]
} |
Eu renomeei as funções para fazer sentido à este post, usava outros nomes. A idéia é usar um objeto feature com as funcionalidades que desejo e usar uma função support, para definir quais delas existirão.
Já tentaram pegar o estilo de um elemento que foi definido apenas no Css? Assim:
1
| alert( document.getElementById("caixa").style.height ) |
O retorno seria vazio, o Js só conseguiria retornar o valor se este fosse antes definido pelo Js ou se usasse style inline (credo…).
Para pegar o estilo do elemento definido apenas pelo Css, nos browsers comuns usamos : document.defaultView.getComputedStyle
Porém no iE, se usa: document.getElementById(”caixa”).currentStyle
Agora, utilizando as funções anteriores, o feature detecting ficaria:
1
2
3
4
5
6
7
8
9
10
11
| function support(){
var support = {}
// Style:
try{
document.defaultView.getComputedStyle
support["computedStyle"] = function(el, att){
return document.defaultView.getComputedStyle(el, null).getPropertyValue(att) }
}
catch(e){ support[“computedStyle”] = function() {return null} }
return support
} |
Este código não verifica qual navegador o usuário está usando, porque aqui não interessa.
O script vai testar se o navegador possui a propriedade, se possuir, constrói um objeto support[“computedStyle”] , que é uma função que retorna o estilo do objeto HTML. Definindo esta propriedade no support, eu teria meus objetos features da seguinte forma:
feature( support() )
// …. Códigos e mais códigos
alert( feature.computedStyle ) // Mostraria o corpo da função computedStyle.
O instinto nos levaria a colocar a função que contém a propriedade currentStyle no catch e fim. Mas aí estaríamos assumindo que todos os navegadores usam a propriedade do document.defaultView e os que não usam são os iE´s da vida. Mas não é a melhor forma de pensar.
A melhor forma de fazer isso seria aninhar mais um teste verificando se o navegador possui a propriedade currentStyle, e retornar uma função conveniente. Há um sério problema nesse caso, não é possível testar o currentStyle, porque ele pertence à um objeto HTML, que não sabemos qual vai ser até a função ser chamada.
Ele tem a forma : elemento.currentStyle.height. O support definiria todas as funções antes mesmo do documento estar pronto, não daria para testar um elemento, sem saber qual elemento é.
Outro instinto ( assassino) seria testar um activeXObject para saber se é um iE ou ainda testar pelo navigator.appName se é um iE6. Isso seria completamente o oposto do que a filosofia do feature detecting prega. Estaria retornando às técnicas de browser sniffing.
A solução que eu encontrei foi essa:
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
26
27
28
29
30
31
| function feature( support ){
for ( var x in support )
feature[x] = support[x]
}
function support(){
var support = {}
// Style:
try{
document.defaultView.getComputedStyle
support["computedStyle"] = function(el, att){
return document.defaultView.getComputedStyle(el, null).getPropertyValue(att) }
}
catch(e){
support["computedStyle"] = function(el, att){
var ieComputedStyle = function(el, att){
if( att == "opacity" && el.filters )
return parseFloat(support["computedStyle"](el, "filter").replace(/\D/gi, '')/100)
return el.currentStyle[att]
}
if(el.currentStyle){
feature["computedStyle"] = ieComputedStyle
return ieComputedStyle(el, att)
}
return feature["computedStyle"] = function(){ return null }
}
}
}
feature( support() )
alert( feature.computedStyle ) |
No catch a função computedStyle testa se o elemento passado como argumento possui uma propriedade currentStyle. Se possuir, o objeto feature.computedStyle é alterado e passa a ser uma função que retorna o currentStyle do elemento. Essa função também teria de tratar o atributo “opacity” , porque se for um iE que estiver executando e este iE não tiver opacity, mas um filter, ele vai funcionar da mesma forma.
Neste ponto ela é recursiva, porque chama ela mesma para retornar a propriedade filter. Para os navegadores que implementam o document.defaultView.getComputedStyle o método computedStyle do feature vai ser implementado logo no load do código. Já os outros, o método seria definido apenas após a sua primeira chamada.
É fácil de enxergar isso fazendo:
feature( support() )
var obj = document.getElementById("box")
alert( feature.computedStyle ) // Mostra função de teste
alert( feature.computedStyle ( obj, "height" ) ) // Chama a função de teste e define o método novo para feature.computedStyle e retornando o valor do height.
alert( feature.computedStyle ) // Mostra o método finalNão seria mais necessário haver testes, cada navegador implementaria a sua função. Entenderam a idéia mais ou menos?
Então, esse trecho acima deve funcionar no Opera, Chrome, FF2, FF3, IE6, iE7 sem que fosse necessário qualquer detecção de browser, em nenhum momento especifiquei no código que navegador deve funcionar em cada trecho.
Para os que quiserem uma literatura mais refinada sobre esse assunto, sugiro este link:
http://docs.jquery.com/Utilities/jQuery.support.
Lá possui 3 links sobre feature detecting, usei um deles no primeiro exemplo. Tem um ótimo exemplo para um método clipBoardData. Eu também deixei um trecho com mais “features”, XML, Ajax e opacity para ajudar a entender a lógica que usei.
Para quem estiver interessado, está aqui :
http://edu.110mb.com/demonstracao/feature.detecting.js.
Um abraço a todos
Valeu!
