Estávamos usando o jQuery até então, que é uma biblioteca JS, que contém inúmeros plugins, além de vários facilitadores para construção de aplicações mais interativas. Acho bacana terem surgidos várias bibliotecas JS, onde o jQuery talvez seja a principal dessas, pois com isso o nível de interatividade entre o usuário e as aplicações aumentaram consideravelmente e isso trás (ou pelo menos deveria) outros prós, como: facilidade de navegação e usabilidade mais intuitiva nas interfaces que fazem o bom uso desses recursos. Para os desenvolvedores sem dúvidas também foi algo positivo, pois é bem tranquilo hoje fazer uma requisição ajax com uma linha de script, além de termos também um código mais organizado e estruturado.

Só que eu sempre tive um certo receio em relação a essas bibliotecas, não com as bibliotecas em si, mas da forma que alguns desenvolvedores as usam, principalmente em caso de aplicações para um grande número de acessos em um ambiente mais “pesado”, já vi alguns casos em que o uso dessas bibliotecas atrapalhou mais do que ajudou e recentemente isso aconteceu comigo.

Utilizei um plugin do jQuery pronto para criar wizards de formulário, ou formulário no formato de wizard, como preferir. Esse plugin, além de ser pouco flexível, causou um problema na minha aplicação justamente no wizard que possui vários inputs. O problema é que ao entrar nesse wizard, o browser simplesmente para durante uns 3s, respira, e depois mostra o wizard, e vamos combinar que isso é muito esquisito, não é um comportamento normal. Para ser sincero não consegui identificar a causa principal, mas desconfio de várias coisas, primeiro é que no geral essas bibliotecas são muito pesadas, só para esse wizard de form eram mais de 50kb de arquivo, algo desnecessário, ainda mais considerando um ambiente com MUITO VOLUME de acessos, pois isso acaba causando um overhead. O segundo é em relação ao código da função para geração do wizard, achei o mesmo extenso demais para fazer algo que funciona, mas que é pouco flexível. O terceiro é que essas bibliotecas JS já são uma abstração de N componentes nativos do JS e por mais que seja ínfimo, isso também pode ajudar a causar um overhead.

Mediante a esses percalços e também a falta de flexibilidade do script que eu utilizei, resolvi criar o meu próprio script para fazer o wizard do formulário, esse script é bem simples, não utiliza nenhuma biblioteca JS, é bem fácil de entender e extender, além de ser flexível. Falando assim parece até uma maravilha do mundo moderno hehe, mas realmente o script resolveu meus problemas de performance e me deu a flexibilidade que eu queria. Testei o mesmo no Firefox 3, Opera 9 e IE 7 e funcionou perfeitamente e da mesma maneira em ambos.

Para visualizar o script funcionando, basta clicar aqui, para fazer o download do mesmo, é só clicar aqui.

Se surgirem dúvidas ou problemas, sugiro criar um comentário que responderei somente por aqui, até porque caso outras pessoas que venham a utilizar o script tenham a mesma dúvida, já fico mais fácil de achar e procurar.

A especificação do protocolo HTTP diz, que o mesmo possui 8 métodos, porém os métodos geralmente mais usados são GET e POST. Quando aprendemos a desenvolver para Web, é comum lermos ou sermos informados, que o método POST deve ser usado em formulários e que o método GET deve ser usado através de links. Isso é uma inverdade.

Tanto o método GET, como o método POST, podem ser usados de várias maneiras, contudo existem boas práticas que indicam as melhores maneiras de fazer o uso desses métodos, a seguir explicarei melhor quais são essas maneiras.

Explicando GET e POST

O método GET faz a passagem de parâmetros para o servidor HTTP através de uma URL, enquanto o método POST envia um documento ao servidor HTTP com o conteúdo contido nesse documento (message body).

Quando usar GET e quando usar POST?

O método GET deve ser usado para acessar recursos, ou seja, para recuperar informações (dados), enquanto o método POST deve ser usado em ações que modifiquem essas informações.

Sendo mais claro, o método POST é usado em ações destrutivas, como: inscrição em algum serviço, modificação do estado de algum recurso no banco de dados, etc. Enquanto o método GET é usado em ações não destrutivas, como: buscas, listagens, etc.

Na prática

GET deve ser usado em operações seguras, justamente por ser indicado em ações que não modifiquem o estado de um recurso, pois imagine que você tenha em sua aplicação um link (GET) que leve a remoção de um determinado ítem, o que poderia acontecer no caso desse link ser indexado por algum web crawler? Pois bem, esse é um dos casos no qual o método POST seria indicado (operações não-seguras).

Exemplos reais

GET: query, buscas, filtros, listagem.

POST: inscrição em serviços (newsletter, por exemplo), alteração/edição/remoção de recursos em banco de dados, envio de email.

Referências

Architecture of the World Wide Web

The fundamental differences between “GET” and “POST”

URIs, Addressability, and the use of HTTP GET and POST

Form Submission

Após incluir a prototype e testar a página, percebi que um erro de JavaScript estava ocorrendo, no começo achei que a causa do erro era em razão de uma função – usando a prototype – que eu tinha acabado de fazer, mas depois usando o bem dito firebug e fazendo alguns debugs, percebi que o erro era mesmo em um conflito entre a jQuery e a prototype.

O problema ocorre, pois as duas bibliotecas fazem o uso da função “$()” para acessar as suas funções, o que acaba gerando o conflito.

A biblioteca jQuery fornece algumas maneiras de resolver isso, mas todas giram em torno da função jQuery.noConflict(). A solução que oferece o maior custo x benefício na minha opinião, é a que eu não preciso alterar os meus métodos já existentes, ou seja, não precisaria ter que fazer isso:

No caso acima, se eu já tivesse N funções usando jQuery, eu precisaria fazer uma refatoração do meu código para mudar o método “chamador” das minhas funções de $() para $j(), isso geraria algum tempo perdido com muitas mudanças e muitos testes. A solução que encontrei pede apenas para que as funções fiquem dentro da document ready area da jQuery, então ficaria mais ou menos assim:

Da maneira acima eu não precisaria mudar nenhuma função já existente, bastaria apenas incluí-las dentro do bloco indicado.

Segundo a documentação, essa seria a solução mais adequada na maioria dos casos.