Uma das minhas ferramentas favoritas da actualidade é o jQuery mas não vale a pena estar sempre a repetir de que forma ela altera todo o processo de desenvolvimento client-side web.

Algo que passou a ser bastante trivial de fazer foram as chamadas ajax. Por esta altura já toda a gente sabe que a técnica em si mesma não é nova mas de qualquer forma não fossem um conjunto de técnicas e ferramentas que surgiram nos últimos anos e ainda estariamos na web1.0

Assim, para fazermos pedidos Ajax em jQuery temos simplesmente que:

     $.ajax({
        type: "GET",
        url: endereco.aspx,
        dataType: "text",
        data: { 'Operation': 'nome',
                'nome_parametro1': 'valor_parametro1' },
        success: function(data, textStatus){
                   alert('ok');
                 },
        complete: function(XMLHttpRequest, textStatus){
                    alert('fim');
                  },
        error: function (XMLHttpRequest, textStatus, errorThrown) {
                  alert("erro:" + XMLHttpRequest.responseText);
              }
      });

      alert('teste');

De notar que neste exemplo estou a assumir que o resultado vai ser um pedaço de JSON.
Uma questão que convém sempre relembrar é que, pelo menos neste exemplo, as chamadas são assíncronas (é o primeiro A de Ajax), e por isso a ordem pelo qual o código é executado pode pregar algumas partidas, ou seja, aquele ultimo alert(‘teste’) poderá não correr só depois de completada a instrução $.ajax já que, a partir do momento em que é feita a chamada ajax, esse bocado do código passa a correr “paralelamente” (não é, mas quase) ao código que está na instrução seguinte (neste caso o alert(‘teste’).
De referir ainda que o bocado que está no “complete” vai ser sempre executado indepdentemente do resultado ter sido “success” ou “error”.

Uma funcionalidade muito interessante que o GMail tem é, quando fazemos uma pesquisa, sublinhar depois no mail a palavra que procuramos. Em principio isto deverá permitir que o utilizar direccione mais rapidamente a sua atenção para o pedaço de texto que realmente interessa.

(rever os artigos “F-Shaped Pattern For Reading Web Content” e “Top Ten Mistakes in Web Design” de Jakob Nielsen)

Como a aplicação que estou a desenvolver é, a nivel de conceito pelo menos, um motor de pesquisa achei que fazia todo o sentido usar algo do género. O meu cenário é o seguinte, tenho uma página onde vou pondo uns filtros e a dado momento quero ver o resultado da pesquisa por esses filtros. Na página que mostra esse resultado estou quero então, de alguma forma, destacar as palavras que usei como filtro.

Como estou a usar intensamente o jQuery (que como já disseram “Puts the Fun Back into Browser Scripting“) procurei um plugin que já fizesse isso. Encontrei alguns e estou a usar o “Higlighting jQuery plugin” que faz quase tudo o que queria.

Tive que fazer 3 alterações:

• o código original tinha um if inicial com código diferente para IE e para os outros browsers mas por alguma razão no IE a função não se limitava ao contexto definido na chamada da função (por exemplo um div) e fazia o highlight da palavra em todo o documento. Optei pela solução radical de comentar esse código e usar só a parte para os outros browsers mas que funciona também em IE;
• o código original seleccionava todas as instâncias da string que nós indicassemos, por exemplo se dissesse para fazer o highlight de palavra “joão” essa função ia seleccionar quer a palavra joão quer todas as outras variações sobre essa palavra. como não era esse o meu objectivo acrescentei um novo parâmetro chamado “exactValue” para destacar só as palavras que fossem exactamente iguais à palavra indicada;
• finalmente esta função obrigava à existência de uma css classe chamada highlight e tinha esse nome hard-coded. como não me dava muito jeito acrescentei um novo parâmetro opcional com o nome da classe que queremos usar.

O código final que estou a utilizar e que enviei ao autor original é o seguinte:

/*

highlight v2

Highlights arbitrary terms.



MIT license.

Johann Burkard



*/

$(function() {
/* jQuery.highlight = document.body.createTextRange ? */
jQuery.highlight =
/*
 (Complicated) version for Mozilla and Opera using span tags.
*/
  function(node, te, exactValue, className) {
   var pos, skip, spannode, middlebit, endbit, middleclone;
   if (className == undefined) className = 'highlight';
   if (exactValue == undefined) exactValue = false;
   skip = 0;
   if (node.nodeType == 3) {
    pos = node.data.toUpperCase().indexOf(te.toUpperCase());
    if ((pos >= 0) &&
		(exactValue ?  $.trim(node.data.toUpperCase()) == $.trim(te.toUpperCase()) : true) ) {
     spannode = document.createElement('span');
     spannode.className = className;
     middlebit = node.splitText(pos);
     endbit = middlebit.splitText(te.length);
     middleclone = middlebit.cloneNode(true);
     spannode.appendChild(middleclone);
     middlebit.parentNode.replaceChild(spannode, middlebit);
     skip = 1;
    }
   }
   else if (node.nodeType == 1 && node.childNodes && !/(script|style)/i.test(node.tagName)) {
    for (var i = 0; i < node.childNodes.length; ++i) {
     i += $.highlight(node.childNodes[i], te, exactValue, className);
    }
   }
   return skip;
  }

 ;
});

jQuery.fn.removeHighlight = function(className) {
 if (className == undefined) className = 'highlight';
 this.find("span." + className).each(function() {
  with (this.parentNode) {
   replaceChild(this.firstChild, this);
   normalize();
  }
 });
 return this;
};

Até há uns tempos atrás o principal mecanismo de feedback numa aplicação web era o próprio recarregar da página quando fazíamos alguma coisa, fosse clicar num link, carregar num botão de um form, seleccionar uma opção numa combobox… praticamente qualquer interacção que provocasse previsivelmente uma resposta iria levar a que o servidor nos brindasse com esse compasso de espera que não era mais do que ir até ao servidor buscar a resposta que tinha sido pedida.

Numa aplicação AJAX em que queremos limitar o número de visitas até ao servidor, ou pelo menos restringir esses pedidos à informação necessária e suficiente para responder ao pedido (em vez de mandar sempre a página toda) esse feedback “natural” pura e simplesmente desaparece… é o exemplo perfeito de como uma nova tecnologia em vez de levar à redução de trabalho leva ao (re)aparecimente de outros problemas que se pensavam resolvidos.

No meu caso concreto estou neste momento a desenvolver uma aplicação que mistura algumas interacções em modo tradicional (click => reload page) com outras em modo ajax (click => reload area) pelo que é aceitavel que o utilizador não saiba ao certo que tipo de feedback vai ter… será isto um code-smell?, ou melhor UI-smell… no caso concreto acho que não mas tem uma implicação. Tenho que ser extra-cuidadoso no feedback que dou ao utilizador.

Este exemplo tem a ver com o preenchimento de forms. Como garantir que o utilizador é avisado quando sai de um form sem o ter gravado?

Em “Using JQuery to Warn Users About Losing Data When Navigating Away from Form” encontrei a solução que me parece resolver este problema.

$(document).ready(function(){
  $(':input').bind("change", function() { setConfirmUnload(true); }); // Prevent accidental navigation away

  $("form").submit(function() {
    setConfirmUnload(false);
  });

});

function setConfirmUnload(on) {
  window.onbeforeunload = (on) ? unloadMessage : null;
}

function unloadMessage() {
  return 'You have entered new data on this page.  If you navigate away from this page without first saving your data, the changes will be lost.';
}