Hoje volto naquela polêmica de “Validar x Não Validar”, polêmica que foi “ressucitada” pelo Meio Bit, em Webstandards da W3C são apenas uma lista de desejos?.

Continuo defendendo aquele meu velho ponto de vista, mas desta vez vou ampliar um pouco minha “visão da coisa”.

Impor o Firefox como browser a ser escolhido pelo seu cliente é suicídio. Nem tente. No máximo uma sugestão. Mas aí surge um problema: se 80% dos internautas usam Internet Explorer, vale a pena usar os padrões? Já voltamos aí.

Por mais que seu ego diga “Valida logo!”, seu cliente diz “Termina Logo!”. No caso, IE, gambiarra, hack, defeito, dor de cabeça… Se você desenvolve primeiro no Firefox, há uma grande possibilidade de tudo estar validadinho. Se você desenvolve primeiro no IE, nem vou falar.

E aí, já decidiu? Crie tudo primeiro para o Firefox. Quando tudo estiver direitinho, faça as alterações, gambiarras, hacks, comentários condicionais… Vai tudo estar pronto antes (por mais que não pareça), e você satisfez seu ego (isso é bom, né?) e seu cliente (que vai estar feliz por funcionar 100% no IE e por você ter entregue na hora). Além disso, sua impressora fica livre de ter que imprimir alguns currículos…

E a pergunta de sempre: Validar ou não? Sim, sempre que possível (nem sempre há tempo). Não perca seu emprego por um bug do seu código ou do W3C, siga feliz!

Alguns não gostam, alguns adoram, outros usam de vez em quando. O prototype (não o framework), apesar de aumentar um pouco a quantidade de código, pode ser muito útil em certas aplicações. Em outras, nem tanto.

Como já expliquei, o prototype não sobrescreve nada que já esteja definido, portanto, é necessário prestar atenção em um pequenino detalhe.

Há uns tempos atrás, tive um certo problema com a construção do FrameWorX. Não conseguia acessar uma variável que estava fora de uma função que estava usando, mas ainda dentro da classe. Na tentativa-e-erro (leia-se POG), descobri como acessa-la: o prototype. O problema foi que ele não sobrescrevia o valor false. Portanto, nada podia ser definido.

O Princípio

O princípio para o prototype sobrescrever algo é o seguinte: criar esse “algo” com ele mesmo.

function errado() {

  this.variavel = "";

}

errado.prototype.variavel = "Outra coisa"; // Assim não dá certo!

function certo() {

  // Não tem nada definido aqui dentro!

}

certo.prototype.variavel = "Outra coisa"; // Assim funciona!

Esse método pode ser usado dentro de métodos privados para acessar variáveis públicas (meu eterno problema foi resolvido!), funções autônomas (aquelas que não tem nome, tipo window.onload = function() {…}) ou para criar toda a classe.

Criando a Classe

Podemos criar a classe inteira com o prototype. Os métodos e propriedades podem ser adicionados através dele, e inclusive o corpo do construtor, e nada ficaria dentro da definição da função.

Nesse caso, nem sempre é uma boa. Não sei quanto à questão do desempenho, mas o código fica sensivelmente maior, às vezes desnecessariamente.

Espero que não tenham ficado dúvidas. Qualquer coisa, comente!

O blog do Ajax Online está, digamos, online. Só falta eu aparecer por lá. O Tiago Neves deixou, recentemente, o artigo “Criptografia, um bicho de mais de 128 Kabeças” (link quebrado…), e de lá saiu a idéia para este post.

Importância da Criptografia

A Criptografia, “arte” de “esconder” dados, foi criada há muito tempo atrás. Uma das primeiras utilização de criptografia foi pelos hebreus, a Cifra de Atbash. Ela consistia em trocar a primeira letra do alfabeto pela última, a segunda pela penúltima e assim por diante. Para nós, óbvio. Para eles, útil e avançado.

A criptografia usada hoje em dia é muito mais sofisticada que essa. Ela pode usar várias técnicas diferentes, separadas ou juntas (criptografar um texto criptografado usando outra técnica pode ajudar).

Pense na seguinte situação (clichê do Tiago): você tem seus dados navegando pela rede, rumo ao seu destino. Então esses dados são abordados por um estranho, um lobo-mau da história, que os intercepta. Se esses dados forem confidenciais ou importantes, temos um problema.

Portanto, aí fica evidente a necessidade de criptografia.

Onde Utilizar

Em certas aplicações, a criptografia não é necessária. Enquetes, sugestão de texto, leitores de RSS ou qualquer coisa parecida, com criptografia embutida, ficarão mais lentos sem necessidade alguma. Qualquer um pode (e talvez deve) ver esses dados.

Caso você trabalhe com senhas (qualquer uma), ou dados pessoais de outras pessoas, a criptografia deve entrar em cena.

Obviamente, devemos enviar e receber os dados criptografados, e armazena-los assim também. Assim sendo, você precisa de um encriptador e um desencriptador em ambos os lados da aplicação: servidor e cliente. Eles precisam funcionar igualmente, então eles precisam ser portáveis.

Qual Utilizar

Como existem hackers por aí, quanto melhor for a sua criptografia, mais seguros estão seus dados. O problema é que o encriptador/desencriptador deve estar no servidor e cliente.

Para dados menos “críticos”, você pode criar uma criptografia que se adapte as suas necessidades. Como diz o Tiago, algo de pessoal sempre ajuda.

Fico devendo um script, não sou bom nisso. Pretendo implantar algo assim no A-FW. Assim que estiver OK disponibilizo o código.

Algumas Controvérsias

Peraí, mas se vamos encriptar/desencriptar no cliente, precisaremos da chave, certo? Então essa chave deve estar no código que está no cliente, ainda certo? Pense bem… Além disso, o código do encriptador está no cliente também, o que nos traz mais um problema.

Assim sendo, qualquer hacker que saiba o que é JavaScript (aliás, nem precisa ser hacker, qualquer um de nós mesmo) poderia descobrir o código. Isso não é bom não!

Por esse motivo, a criptografia deve ser bem pensada. Algo como envio da chave por Ajax, verificando o referer (foi o máximo que consegui). Se o referer estiver errado, nada de chave, ou uma chave errada! Chaves grandes, criptografias rápidas, mas complexas. Há muito a se pensar. Boa sorte!

O 24 Ways está de volta. Desde o dia 1º até o dia 24 de dezembro, serão apresentados vários artigos “muito dos interessante”, escritos por grandes gurus da web.

Dentre esses gurus, temos: Inman, Hicks, Collison, Johansson, Molly além do próprio McLellan, criador do site.

Alguns dos temas abordados: CSS, DOM scripting, acessibilidade, microformats dentre outros. Ahh! Também estão disponíveis os artigos do ano passado: 24 Ways 2005.

Espalhe a notícia! Fonte: Revolução Etc

Além de texto simples e JSON, existe outra maneira (e muito eficiente) de trocar dados em Ajax. Essa maneira chama-se XML, e considero-a a melhor maneira para trocas de dados mais complexas, envolvendo várias partes de dados.

O XML

Bem, XML já devia ser algo conhecido para você. Não precisa saber muito, só como colocar as tags e o CDATA (esse outro eu explico).

Qualquer XML válido (sem nenhum erro de “ortografia”) pode ser usado, mas uma certa padronização ajuda. Eu costumo sempre usar o seguinte XML, para quase todos meus trabalhos mais recentes:

<?xml version="1.0" encoding="iso-8859-1"?>
<ajax-response>
  <head></head>
  <body></body>
  <foot></foot>
  <other></other>
</ajax-response>

Esse é um código padrão que eu uso, sinta-se livre para mudá-lo. A tag head trará informações de cabeçalho (eu utilizo como <hN> ou mesmo no título da página). A tag foot trará informações de rodapé, mas nem sempre uso. A tag body traz tudo o que aparecerá na página, como todo mundo já usa. A tag other não costumo utilizar muito, apenas para trazer informações de script (arquivos a carregar, variáveis de funcionamento…). Dependendo de sua aplicação, você pode usar RSS, RDF, SOAP…

Como provavelmente incluiremos tags dentro dessas tags, que servirão para serem renderizadas, e não processadas, precisamos colocar elas dentro de uma seção CDATA. Ela faz com que o parser XML ignore tudo que estiver dentro. Use-a assim:

<body>![CDATA[
Aqui vão os dados
]]></body><

Recomendo que você use isso em head, body, foot e other, para evitar futuras dores de cabeça.

O JavaScript

Para recuperarmos esse XML, fazemos a requisição normalmente e pedimos responseXML, ao invés de responseText: var xml = [XHR].responseXML;.

Lembra-se de DOM? Vamos utilizá-lo aqui para “pegar” o que está em nosso XML. Tudo seria mais fácil se o IE suportasse E4X (posso sonhar, não?)… Ele é bem parecido com o HTML DOM, mas não me venha usar innerHTML (não testado, mas pela lógica: HTML!) e getElementById (também não testado. Se der certo, alguém me avisa! funciona sim, como o Micox disse nos comentários).

No básico, usamos isso:

var body = decodeURIComponent(xml.getElementsByTagName('body')[0].firstChild.data);

Tudo certo. Acabamos? Ainda não. No Firefox (não me pergunte por que), o CDATA é cortado a cada 4096 bytes (4Kb). Nesse caso, temos que pegar vários CDATA caso tenhamos mais de 4Kb. O código é esse:

for(var i=0; i <
xml.getElementsByTagName('body')[0].childNodes.length; i++) body += decodeURIComponent(xml.getElementsByTagName('body')[0].childNodes[i].data);
// Pegamos cada node e adicionamos na variavel

E pra que isso?

XML é muito usado em Web-services, por ser mais “padronizado” que texto (o SOAP é muito usado pra isso). Caso você queira um Leitor de RSS, é possível também. Um leitor de RDF, por que não? As utilidades são muitas.

O futuro (longínquo) da Web é XML. Seria bom que você aprendesse o “basicão” como eu. Além de ser legal, você verá que pode utiliza-lo em muitos lugares. E isso facilita e melhora o envio e recebimento de dados, dando a você muitas opções do que incluir ou não.

Update: o Bernardo fez um ótimo post sobre criar gráficos através de XML e Ajax. Lá tem mais umas vagas informações que não foram passadas aqui, leia lá!