Continuando nossa saga de evitar Eval e conhecer melhor o Javascript, vou brincar com a seguinte situação: parsear um template html escrito com Expression Language da spec JSP.

Imagina o seguinte trecho abaixo:

<c:if test="${sessionScope.cart.numberOfItems > 0}">
  ...
</c:if>

É fácil montarmos um mapa com todas as expressões encontradas entre ${ e } e depois chamar eval para processar, mas como quero evitar essa chamada, o que podemos fazer?

Encontramos na documentação de referência da Mozilla a resposta, especificamente no objeto nativo Function, onde podemos criar uma new Function passando seu corpo como uma string que será executada ao fazer a chamada dessa function. Montei abaixo um exemplo como funciona:

Caso não veja no seu Feedreader, link do github.

Posted in JavaScript ~ 3 Comments

Fiz um teste nesse momento em 4 navegadores que utilizo no dia-a-dia usando o projeto Sputnik do GoogleLabs para saber a aderencia à especificação ECMA 262. Fiz um teste sem compromisso e sem rigor acadêmico, apenas por curiosidade.

Esse teste é interessante para sabermos que possíveis problemas irão acontecer por diferença de implementação do Javascript por cada engine.

Firefox

Total:	5246
Succeeded:	4982
Failed:	264

Versão 3.6.16

Opera

Total:	5246
Succeeded:	5172
Failed:	74

Verṣo 11.01 РBuild 1190

Chrome

Total:	5246
Succeeded:	5110
Failed:	136

Versão 11.0.696.57

Safari

Total:	5246
Succeeded:	5083
Failed:	163

Versão 5.0.5 (6533.21.1)

Voltei…

O interessante é observar que o Opera é o mais aderente, o Firefox o mais lento [travou], o Chrome o mais rápido. Para não ser injusto com o Firefox, eu ainda matei o processo, abre uma instância novinha e mesmo assim ele travou na execução, abriu aquela janelinha marota pedindo para encerrar o script.

A velocidade e economia do Chrome é realmente impressionante, observe os processos:

Dados da minha máquina:

[update]

Como eu sei que alguém vai me acusar de parcial, etc e tal, eu resolvi abrir uma VM aqui com XP e IE8 para não dizerem que não falei de flores … olha só:

Ok, é má vontade… Sério?

Uns 10 minutos depois e sem voltar [continua travado], já basta esses dados para mostrar que o IE8 é uma bo$ta em relação a aderência [imagina o 6]:

Posted in JavaScript ~ No Comments

Problema que detectei em algumas applicações que estamos desenvolvendo com Extjs+Jquery: Na máquina de entrega o request do tipo DELETE funcionava tranquilamente, na máquina de produção hospedada no Rackspace quebrava. Como a máquina de entrega estava dentro da nossa rede, suspeitei logo da conexão, firewall e essas coisas.

O @rponte me deu a dica desse post que ele encontrou com o mesmo tipo de problema. Nunca tinha percebido que a spec HTTP nem proibe e nem recomenda corpo em DELETE. Não faz muito sentido enviar corpo realmente em DELETE, mas até aí tudo bem.

Para completar, o Extjs já previa esse problema e o JsonWriter possui uma propriedade chamada “encodeDelete” para você explicitamente definir que não quer corpo em DELETE, por default já vem assim.

No console do firebug eu utilizava o $.ajax e o Ext.Ajax diretamente com a mesma url para enviar DELETE e funcionava, mas na aplicação não funcionava. Conversando com o pessoal da rede eles me disseram que trocaram o firewall recentemente e observando o log a chamada sequer passava por lá, ou seja, provavelmente ele já rejeita qualquer conexão DELETE com body.

Fui analizar o código do Extjs e ele enviava um body, a diferença é que era vazio, mas ia. Fiz um hack para destruir qualquer parametro quando a conexão fosse para o DELETE e consertou, como pode ver no código abaixo:

Link caso não consiga ver no seu reader.

Posted in Ajax, Ext, JavaScript, Jquery, REST, Web Development, XMLHttpRequest ~ No Comments