Webpoint

Antes de ler este post, aconselho lerem primeiro a parte 01.

Logo abaixo vai a solução postada no grupo oficial do Jquery.

Houve um recente alvoroço de emails na lista de discussão sobre o conflito com o uso do Mootools em conjunção com o Jquery. Quando o Mootools lançou a versão 1.1, eles renomearam seus eventos expando para $events, deste modo haveria um conflito instantâneo com o jQuery.

Bem, o desenvolvedor brasileiro Alexandre Magno http://blog.alexandremagno.net/) veio com uma publicação com uma simples solução sobre este problema, renomeie o $event expando no Mootools!

“Eu encontrei uma solução que trabalha perfeitamente. Eu sou o exemplo vivo de que precisamos as vezes usar ambas frameworks. Eu desenvolvo todos os meus projetos em Jquery, por que foi a que aprendi mais fácil e me sentir mais confortável. Nada contra o Mootools, que é uma bela framework também... Mas eu precisei do Fancy Upload para trabalhar e só é possível com o Mootools, eu fiz tudo, mas não funcionou por causa do conflito com a variável $event. Eu resolvi este problema baixando o mootools sem nenhuma compressão, usei um software como aptana, dreamweaver, ou até mesmo notepad para substituir todas as ocorrências de $event para $event2 por exemplo, e comprimi novamente a biblioteca novamente. Desta maneira, as duas frameworks trabalham perfeitamente, desde que usando o jquery com o noConflit devidademente configurado. Eu espero que isto funcione e breve eu irei desenvolver um sistema de upload para jquery para não ter que usar ambos. É uma vergonha para a equipe do Mootools esperar o jQuery resolver este problema em que ninguém é culpado... é só convenção... por que simplesmente não mudam $event para $mootoolsEvent ou $mooEvent por exemplo??? As vezes é necessário usar ambas, sem dúvida.”

Isto foi postado no forum do MooTools em resposta há um post em que John e eu estávamos tentando resolver um problema de integração de um para um usuário que deseja usar MooTools e jQuery juntos. Nós percebemos o quão irrealista esperar que desenvolvedores irão usar somente uma framework e a equipe vem fazendo grandes esforços para garantir um nível satisfatório de integração entre outras bibliotecas com o uso do noConlict(). No jQuery v1.2, nós fomos mais além para permitir o renomeamento dos eventos expando para qualquer que seja, evitando qualquer conflito.
Enquanto isto não seja um bug do jQuery, nós nos sétimos muito e desenvolvedores integrarem suas ferramentas e nunca trabalhando para que o jQuery seja um gargalo.
Obrigado John e a equipe do jQuery por continuar fazer o jQuery uma solução flexível e obrigado a você Alexandre por expandir o alcance do jQuery para os brasileiros e oferecer esta saída.
Rey...

Gostaria de agradecer o Ray pela oportunidade e ao invés de mostrar o funcionamento do Fancy Upload, irei desenvolver como prometido uma ferramenta semelhante para o jQuery. Vai ser meu primeiro plugin, então mãos à Obra. Dúvidas com o noConflict() será postada aqui breve.

Tudo começou com o sistema de Uploads do Flickr. Fiquei fascinado como era eficiente, fazia tudo que era necessário no client side e depois enviava de forma incrível. Já vi algo parecido em um dos plugins do Jquery chamado JqUplodad , mas o upload na verdade era com Flash e ainda por cima não suporta múltiplos uploads. Fiquei fascinado com a solução do Flickr . Resolvi então pesquisar, tentei achar dicas no código que eu pudesse saber o que estava acontecendo por trás daquilo tudo. Não, não é Ajax. Como o tamanho do arquivo do cliente aparecia antes mesmo de ser mandado temporariamente para o servidor? O Javascript não permite isto por motivos de segurança. Pesquisei Blogs em inglês e um sujeito chamado Beau Collins teve a mesmo fascínio. Quando cheguei em casa fui olhar mais profundamente esse sistema e quando entrei(é necessário criar uma conta no Flickr e então é só ir em upload fotos e você verá do que estou falando) pediu o plugin do flash instalado. Flash? Como assim Flash? Eu não estou vendo nenhum Flash! Descobri então um arquivo chamado yuploadcomponent.swf. Ele não faz nada é verdade, mas ele trabalha por trás de nossos olhos.

No Flash há uma classe que não conhecia, chamada File Reference. Ela controla o upload de arquivos no flash e permite que você adicione uma barra de progresso e ainda tenha informações do arquivo do cliente como tamanho, que não é possível com Javascript. A janela que abre quando você clica para fazer o upload na classe do Action Script é a mesma do Flickr, mas o link está em uma página HTML. Não é um HTML dentro do Flash, como muitos poderiam pensar. Mas ainda tinha muitas dúvidas, é uma solução complexa e que devo dar os parabéns pelo trabalho da equipe do Flickr.

O que acontece na verdade

Existe uma outra classe no Flash chamada ExternalInterface que permite interagir o flash com o Javascript e HTML. Assim, quando você clica em um link você pode chamar um Action Script, neste caso do Upload, você executa método File Reference. Além disso, flash funciona simplesmente para esta interação, para buscar dados e então as respostas são controladas pela framework YUI Library. Mas ela foi usada por que é própria da Yahoo, poderia ser manipulada por qualquer Framework, inclusive Jquery e Mootools.

A solução da Mootools

Então descobri o Fancy Upload desenvolvido para Mootools. Nunca achei que iria precisar de outra Framework e nem que iria criar uma categoria para ele. Nada contra, pois a princípio foi uma das primeiras que tentei aprender e usar, não me dei muito bem com ela, ficava restrito a pegar coisas prontas. Com o Jquery o aprendizado "fluiu" mais naturalmente, como para muitos, o Mootools é mais tranquilo.

Implementei então o fancy upload para poder aplicar em um projeto na empresa onde trabalho. Eis o exemplo do seu funcionamento.

Sendo assim, encontrei uma solução em outra Framework, tive uma dificuldade pois não tinha familiaridade com ela, mas consegui. O problema veio depois.

Conflito entre Mootools e Jquery

Na implementação deste sistema de Upload fui obrigado a colocar as duas, pois todo o Javascript do site é controlado pelo Jquery. Desta maneira houve um conflito inevitável entre as duas Frameworks. Apesar do Jquery possuir o recurso de noConflict( um belo esforço da equipe em dar a opção aos desenvolvedores usar o que acharem melhor) ainda há um problema com a variável $event, que é usada nas duas bibliotecas.

Então entrei em fóruns no Mootools e descobri uma discussão exatamente sobre isto e que era um assunto bastante discutido nas duas comunidades. O que se pode tirar desta discussão é que os desenvolvedores do Mootools aconselham o uso de somente uma framework, enquanto que o Jquery cria alternativas para as duas ou até várias serem usadas. Geralmente não há necessidade de usar várias frameworks Javascript em um site, mas para toda regra há uma exceção. Nesta discussão não houve uma solução e eu acabei ficando com um problema e um dilema: tirar o Jquery e fazer tudo em Mootools, ou simplesmente chegar para minha chefe e falar "não vai ser possível implementar, desculpe". Tentei várias coisas, mas nada funcionava.

Resolvendo o conflito entre Jquery e Mootools

A solução é mais simples do que parece e será postada detalhadamente na parte 02 deste post. Não é para atrair sua atenção desenvolvedor, que quer logo soluções sem saber a história do problema ;-). O que aconteceu foi que consegui uma solução e postei no fórum do Mootools. Ela não foi bem aceita na comunidade deles, mas o Rey Bango, um dos desenvolvedores da equipe do Jquery, que estava na discussão fez um artigo no grupo oficial do Jquery sobre a solução que coloquei no forum do mootools. No próximo post colocarei a tradução do artigo que contém a solução.

Existe atualmente várias Frameworks Javascript e todas tem o mesmo objetivo: aumentar a simplicidade e a produtividade desta linguagem. Então qual seria a melhor? Qual alcança mais estes objetivos? Com certeza há muita discussão sobre isto e para alguns uma certa framework javascript é como um time de futebol ou até uma religião. Elas não vieram para disputar umas com as outras, mas sim para dar uma liberdade de escolha para os usuários.

Escolhi o Jquery de maneira intuitiva. Conheci primeiro o Mootools, achei bastante interessante, mas ao ler a documentação não me senti a vontade. Depois com o rails acabei encontrando o script.aculo.us e comecei a "brincar" com algumas funcionalidades, mas ainda faltava alguma coisa. Depois veio o Prototype quando fui trabalhar com o cakePHP. Com poucos dias pude perceber o poder desta framework. Então descobri que ela estava sendo muito usada e respeitada na comunindade de desenvolvedores. No entanto, no primeiro dia de encontro com o Jquery, já estava fazendo muita coisa, principalmente com o Ajax. É muito conciso o fato de que no final das contas nada de Javascript é inserido no HTML. Mas isto é minha opinião, mas ela não é válida quando o que vale no mundo do desenvolvimento web é a prátia e vivências de diferentes plataformas.

Procurando por várias comparações na Web vou mostrar neste post a diferença entre o Jquery e  Prototype, que julgo serem as mais sólidas da Web.

Acho que esta citação de Michael Futreal resume bem a diferença das duas:
Prototype torna o Javascript interessante, é uma ótima framework, é útil e boa de usar. O Jquery é divertido. Ele permite que você selecione os objetos DOM da página com seletores CSS3 mesmo que os browsers não o suportem. Por ele você navega pelo DOM como um livro muito bem escrito
Esta é uma boa diferença. Mas e isto em códigos?
Vou começar a ilustrar um Javascript comum que é utilizado no dia a dia: Tabela com cores alternadas. Assim ficará fácil perceber como é útil o uso de seletores CSS3.
Com o Prototype:

$$("table").each(function(table){
Selector.findChildElements(table, ["tr"])
 
.findAll(function(row,i){ return i % 2 == 1; })
 
.invoke("addClassName", "odd");
 
});

E agora com o Jquery:

$("tr:nth-child(odd)").addClass("odd");

Agora me pergunte qual seria mais simples e intuitivo? Qual você prefere ficar?

Vamos ilustrar mais uma funcionalidade das duas Frameworks: Adicionar Classes dinâmicamente em vários elementos.

Abaixo o código com o Prototype:

$$('.element').each(function(node) {
 
Element.addClassName(node, 'className');
 
}

Com o Jquery:

$('.element').addClass('className');

Como está descrito no Blog do Jquery , o último código é um exemplo claro da diferença de metodologias. Pelo fato do Jquery está passando mensagens para objetos Jquery, o código possui uma sutil mudança. O Jquery não importa se você está adicionando uma classe em um grupo de objetos ao invés de um objeto. O código para ambas as situações é o mesmo. Prototype, por outro lado, requer um iterador(No caso o each que percorre todos os objetos selecionados).

Na medida que seu código fica mais complexo, a escabilidade do Jquery se torna mais fácil, enquanto que loops aninhados se tornam normas em frameworks como Prototype.

A seleção de objetos utilizando o X-path e o CSS3 tornou-se algo tão útil, que a versão do Prototype depois da 1.5 já aceitava essa característica.

Há muitos rumores de que o Jquery seja bem mais lento que o prototype, mas testes foram realizados e pode-se contatar que não é bem assim. A diferença entra na parte da filosofia. Resumindo estes conceitos, para o Jquery:

• Escabilidade: Pelo fato dos objetos Jquery ter funcionalidades "colado" nele, eles retornam outros objetos Jquery, e assim os desenvolvedores podem passar mensagens adicionais para eles.
• Uso de seletores CSS e XPATH: Devido ao Jquery passar mensagens para objetos, ele pode implementar seletores adicionais no método $.
• Desenvolvimento de Plugin: O próprio Jquery conduz ao desenvolvimento de Plugins. É fácil adicionar funcionalidades ao objeto Jquery.
• Looping automático: Os métodos Jquery são requisitados para automaticamente iterarem através de todos os objetos DOM selecionados.

Bem, acho inevitável qualquer desenvolvedor Javascript fazer o uso de uma framework. Para quem ainda não sabe qual usar, vale a pena dar uma olhada no Jquery. Para quem usa o Prototype, nada contra, pois acho que cada Framework se encaixa para um certo desenvolvedor. Eu me dei bem com o Jquery, outros podem gostar do Prototype e achá-lo bem mais simples e intuitivo. Mas tentei mostrar aqui as diferenças e uma comparação entre as duas e o que me levou a fazer esta escolha. O desenvolvimento de Plugins e a seleção por CSS 3 é um diferencial.