Webpoint

Para os usuários, tanto faz. Para os desenvolvedores o medo de ter mais um browser para ser testado e consequentemente, mais dor de cabeça.

Os usuários pouco se importam para novas versões do IE, pois estes geralmente utilizam o que estiver instalado no sistema operacional. Quem usa outros browsers geralmente teve o trabalho de procurar por sua instalação. Esta iniciativa demonstra o mínimo de conhecimento que muitos usuários não possuem.

Já os desenvolvedores Web, lançamento de um novo browser pela Microsoft não é uma notícia animadora.

Mais uma vez, foram relatados vários bugs de segurança e de interpretação do javascript e CSS. Ainda é cedo para dizer, pois estão na versão beta, mas já dá para prever o que acontecerá.

ler artigo completo

Uma das maiores vantagens do jQuery é sua possibilidade de extensão. Criar plugins para ele, uma vez feito, torna-se um vício. Com isto o código fica reaproveitável e e cada vez mais pode ser feito muito com poucas linhas de código.

Vários plugins já se solidificaram e tornam-se essenciais quando você adota o jQuery. Muitos deles em várias discussões no grupo oficial são requeridos para serem adicionados no próprio core do jQuery. Mas os criadores do jQuery não adotam esta idéia, até por que o jQuery precisa continuar limpo e flexível e para isto deve ser somente o jQuery.

Neste post não vou falar detalhado sobre um plugin ou outro, isto ficará para próximos posts. Agora vou somente dar uma visão básica sobre todos e para vocês saberem o quão útil estes plugins são.

Essenciais para o Ajax

Com o ajax, para se cadastrar dados do banco ou pegar dados do usuário digitados em formulários, fica difícil a tarefa "normal" e fácil de pegar os dados e no arquivo de destino no lado servidor eles serem "captados" pela requisição post. Esta tarefa para o javascript precisa ser feita à mão. Sem frameworks, estes dados precisam ser pegos acessando valores de formulários. No entanto, o jQuery tem em seu core o método val() que faz este trabalho. Apesar de facilitar, ela é ainda bastante manual. Com isto, torna-se necessário e muitas vezes essencial o Form plugin para jQuery. Quem ainda não o conhece, trate de conhecer sua documentação como um core do jQuery. Este plugin pega os dados do formulário e faz uma requisição post passando todos os dados transformando todos os names e seus valores para serem acessados no lado servidor normalmente, sem precisar mais nenhum esforço. Além disso, ele possui callbacks para validação e controle dos dados, além de configurar toda a resposta retornada por xml, json ou até mesmo html.

Além disto, ele é integrado com o validate, ou seria o validate integrado com ele? . A verdade é que a parte de validação do form plugin não é tão eficiente e flexível quanto o validate. Este plugin é poderosíssimo e bastante extendível. Você pode fazer toda a validação do lado cliente com ele e até adicionar métodos de validação remota. Quando tudo está ok, o formulário pode ser enviado via ajaxSubmit, um dos métodos do jQuery Form plugin.

Outro plugin que não pode faltar com qualquer site usando ajax, principalmente na navegação é o Live Query, que mantém os eventos após qualquer modificação do dom, mas afinal, o que é isso?

Quando é feita uma atualização por ajax, principalmente usando o método load, a página inserida pelo DOM perde os eventos e suas configurações. Ou seja, se você tiver colocado um link para carregar outra página por ajax, e esta página interna contiver links que mais uma vez executam métodos load, as páginas internas não irão herdar os eventos. É como se eles se "perdessem". Para contornar isto, nos callbacks do ajax, você tem que carregar tudo que irá permanecer novamente. Ou seja, criar funções para fazer requisições e executá-las novamente para que as modificações do dom não percam os seus eventos. Isto é uma tarefa que faz o ajax no jQuery muitas vezes perder sua simplicidade. Sendo assim, com o liveQuery você pode fazer isto normalmente sem perder estas funcionalidades. Ao invés do método bind, vc utiliza o livequery e ele faz com que todo o conteúdo gerado por script herde os eventos, como por exemplo, o ajax. Ele não se restringe somente a isto e tem que ser bastante estudadod, mas se já tiverem tido este problema(e se tentarem fazer a mesma coisa sem ele terão este problema), este plugin resolve muito bem.

Para animações, interface!

Para realizar animações personalizadas, o plugin interface possui tudo o que você precisa. Ele possui uma biblioteca de animaçõs que vão muito além do core do jQuery, além de ter bibliotecas de sortables, draggables e assim sucessivamente. Se deseja fazer animações web2.0, ferramentas de interação totalmente inovadoras, ele é essencial.

O jQuery está também com um esforço de criar o que o scriptaculous é para o prototype, uma ferramenta totalmente completa de interação. Conhecida como jQuery UI,  ela possui uma biblioteca totalmente completa de interação que vai além do interface na tentativa de popularizar e enriquecer a interface de usuário do jQuery.  Ela possui Widgets e métodos de usar bastante simples e personalizável.

Ando tendo problemas com ele, mas provavelmente é devido ao fato de ser bastante novo e tem muito a melhorar, por enquanto vou ficando com o interface.

Bem, a abreviação do CSS já diz tudo sobre sua arquitetura. Ela funciona em cascata. Novidade para uns, obsoleto para outros, mas que quando aplicado da maneira correta, pode te ajudar em muito na leitura do CSS. Bem, o usuário final não vai ver o resultado, mas para desenvolvedores web que se prezem, não importa apenas o resultado final. Como ele foi atigindo também é relevante. Como já disse anteriormente, mesmo sendo uma linguagem de design, o CSS tem várias metodologias e truques por trás da manga.

Você vai entender melhor do que estou falando, irá diferenciar este post de uma weblosofia que não tem prática. Vamos supor que você quer estilizar um campo de formulário e assim você atribuiu uma classe para ele com o nome de campo. Como já mostrei no post hover em campos com o jQuery, você pode colocar outra classe que irá representar o estado hover do elemento, pois como já discuti antes, o IE6 suporta o hover apenas em links.

Assim, ele poderia ser estilizado da seguinte maneira:

.campo {
font-size: 18px;
color: gray;background-color: #DDDDDD;
border: 1px solid #A19A9A;
 
}
 
.campo_focus {
 
font-size: 18px;
color: gray;
border: 1px solid #E64D4D;
background-color: #DBCDCD;
 
}

No campo focus ele muda a cor de fundo e a borda, mas permanece com a fonte 18px. A fonte está especificada por que é diferente das demais, caso contrário ela seria especificada no body, no html ou com o símbolo asterisco que representa todos elementos. Olha o efeito em cascata evidente, pois a classe campo e campo_focus herdaria o tamanho da fonte de qualquer elemento ancestral a ele. Sim, pode considerar o documento como um pai cheio de filhos e que tem mais filhos, ou como uma árvore, pois uma família pode ser representada também por uma árvore. Não importa como você pensa, desde que você tenha isto em mente. Sendo assim, podemos reescrever este css desta maneira:

.campo, .campo_focus {
font-size: 18px;
color: gray;
background-color: #DDDDDD;
border: 1px solid #A19A9A;
}
 
.campo_focus {
border: 1px solid #E64D4D;
background-color: #DBCDCD;
}

Desta vez eu especifiquei o campo e no campo_focus suas propriedades em comum e as que irão ficar somente na classe campo estão declaradas. A segunda vai ter as propriedades diferentes e vai prevalecer no campo_focus as declarações que você colocou por último, obedecendo a herança. Assim, se você mudar o tamanho da fonte, basta apenas mudar em um local. Se não ficou evidente a diferença, vou ilustrar um exemplo mais complexo.

Imagina que você está colocando em um menu um fundo diferente para cada item e que este menu esteja como uma lista não ordenada. Pois bem, haverá várias declarações nos elementos li, mas neste li você terá que colocar um id para diferenciar dos demais para assim no css para cada id tem um background. Então você deve aplicar a frase anterior literalmente: "cada id tem um background", ou seja, a única coisa que diferencia-os é o background, portanto, todos as outras propiedades comuns devem ser declaradas no li e somente o background deve ser declarado em cada id. Isto evita redundância e melhora a hierarquia do seu CSS.

Estava vasculhando os acessos mais remotos do mapa mundi deste digníssimo HD e eis que encontrei um projeto que não saiu da primeira fase. Quando comecei a me aventurar no CSS, haviam poucos sites brasileiros que pudessem abordar o assunto. Dizendo em palavras cruas: era falta de material de pesquisa! Então encontrei um grande refúgio nos livros do O'Reilly. Pensei então em traduzi-lo e aprender com ele, pois traduzindo eu iria estar aprofundando nos textos, além de executar todos os exercícios, pois para mim não basta o cara mostrar e falar que é aquilo, pois Browsers são browsers, você nunca pode esperar nada deles. Já passei tanta vergonha com o bendito IE6, quantos sites estavam funcionando perfeitamente, mas para mostrar ao cliente já era outra história?

O fato é que o livro me ensinou 90% do que eu sei de CSS hoje, pois ele é prático e esta linguagem de programação para design, se é que posso dizer assim, vive em torno da prática. Neste livro ele mostra um problema real e discute de maneira bastante sucinta sobre o assunto. Mostra código, fala dos browsers, apresenta soluções e mostra o que há por trás disto. E no fim onde existe a documentação oficial sobre o assunto e os melhores sites para quem quiser aprofundar.

Hoje há muitas pessoas competentes para abordar CSS no Brasil, sem deixar de citar o Maujor que um dos repercursores e eu presenciei tudo isto acontecendo.

Tinha um projeto de fazer um site só de receitas CSS e o tempo passou, hoje estou escrevendo neste Blog que expandiu o assunto além do CSS, que apesar de gostar muito, eu também me apaixonei pela parte de programação. Não me perguntem o que sou, quero ser um programador designer sim, não, não faço os layouts no photoshop, eu executo idéias. É uma loucura, mas não consigo me agarrar somente ao CSS, e venho achando muitos aliados para continuar assim como o jQuery, que aproxima cada vez mais nas duas. Há e o PHP com uma pitada de Cake também :-D.

Resolvi então deixar este material disponível ao longo do tempo até terminar o livro. É muita coisa. Ele poderá ser útil não só para quem está iniciando, mas ele vai aos pontos que interessa. Espero que gostem e um grande abraços a todos. Abordei um assunto para início de conversa que já me indignou muito, já se perguntaram que se existe o hover para usar em todos os elementos, por que ele só é aceito em links no IE6?

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.

Quando desenvolvi este Blog fiquei muito fascinado nas ferramentas que o Wordpress oferecia e não fiz mais nada além de desenvolvê-lo. Esqueci do "pequeno" detalhe de pesquisar outros blogs do assunto. Só agora que me tornei um "blogueiro" que andei "vasculhando" a comunidade de desenvolvedores Web e percebi o quanto ela é competente e ativa. Tantos desenvolvedores com dois fatores em comum: Web Standard e Jquery. É incrível como esta framework torna mais bonito o desenvolvimento Javascript. Mas deixe o meu fanatismo com o Jquery em outros Posts.

Para começar, ao entrar no fórum do IEvolution encontrei uma comunidade que  ajuda para o que precisar. Então  acabei por chegar no Jquerybrasil, que possui toda a documentação da Framework em português, o que ajuda bastante bons desenvolvedores que não dominam a língua como meu colega de trabalho Daniel Mariz, quanto outras que gostam de ler na sua língua, afinal, somos brasileiros!

Poderia citar aqui uma infinidade de links dessa comunidade, mas dêem uma olhada no Blogroll, por que ele irá crescer a medida que for encontrando os "fiéis" :-).

Depois de navegar por tantos conteúdos e desenvolvedores dedicados em mostrar as vantagens da framework e da Web Standandard, por que não usar o Jquery?