O número dessas bibliotecas é incontável, algumas mais simples, outras mais complexas, outras mais famosas, algumas nem tanto. Fiz uma breve pesquisa, e trouxe as mais conhecidas (e algumas nem tanto) para quem ainda não teve a oportunidade de conhecer. Só para lembrar, hoje não vou tratar sobre o uso dessas bibliotecas, isso fica pra uma próxima oportunidade, já que a idéia é um pouco extensa.

ExtJS

A ExtJS é de longe a biblioteca mais conhecida. Provavelmente você já deve ter pelo menos ouvido falar sobre, a menos que você viva na Sibéria. Também acredito que deva ser uma das mais antigas, e por isso uma das mais completas também.

Seu visual é espetacular, mas tem seu preço: ela é muito lenta. Todos os efeitos de transparência, os drag ‘n’ drops, tudo isso exige muito do pobre navegador. Pense bem antes de escolher onde usá-la, faça somente se for necessário, nunca para simples “enfeites”. Lenta, mas uma obra de arte.

E os desenvolvedores AIR não precisam ficar tristes: há até um demo do bichinho em funcionamento. Ainda não tive muito tempo com o AIR, mas acredito que a questão da velocidade não seja tão crítica quanto em um navegador, quem puder falar sobre, agradeço.

Yahoo User Interface

A Yahoo User Interface, ou YUI, deve ser a primeira user interface a se popularizar. Foi a base do nascimento da ExtJS. Tem lá seus defeitos, como o prefixo YUI para todos os métodos, mas tem um poder imenso. Me parece ser bem mais leve que a Ext, e usa gráficos bem mais simples também.

A documentação é um dos pontos fortes. Mantida pela comunidade de desenvolvedores do Yahoo, você nunca estará sozinho. Apesar disso, achei o site um pouco confuso para encontrar alguma coisa, principalmente os demos. Mas o material está lá, e há muito…

MochaUI

Ainda beta, a MochaUI seria a minha preferida. Adivinhem por quê? Sim, baseada na Mootools… A demonstração realmente me deixou impressionado, talvez tenha sido o relógio.

Aparenta ser bem leve, tanto que na demonstração você pode modificar propriedades das janelas sem travar o navegador. Usa gráficos simples, mas não menos atraentes. De longe, seria a primeira que eu escolheria para trabalhar (sim, opinião extremamente parcial). Mal posso esperar pela versão 1.0!

Dijit

Falando em Dojo, nem é preciso dizer muito. O framework mais abrangente que conheço também conta com sua interface de usuário, o Dijit. Não consegui encontrar demonstrações no site, mas as imagens mostram algo realmente promissor.

Lendo a descrição do projeto, você verá que o Dijit não é apenas uma simples interface de usuário. É extremamente customizável, extensível, acessível e localizável. O que isso significa? Bem, dê asas à imaginação, o céu é o limite…

jQuery UI

O jQuery UI, bem jovem ainda, também é espetacular. Baseado na brilhante jQuery, tem tudo para deixar qualquer um de boca aberta. A demonstração de efeitos, por exemplo, me impressionou muito. A própria tela de demonstrações é uma obra de arte.

Apesar de baseada no jQuery, achei a biblioteca ligeiramente lenta. Talvez tenha sido impressão, mas não esperava isso de jQuery. Entretanto, pela sua idade, é muito madura, muito poderosa. Se jQuery não havia me chamado atenção ainda…

Prototype UI

Até então desconhecido pra mim, o release candidate Prototype UI não conseguiu me chamar a atenção. Não por ser baseado em Prototype e Scriptaculous (o que já considero um ponto contra), nem por usar um tema do Mac, mas por parecer muito prematura. Os demos apresentados são bonitinhos, mas um tanto “crus”. Prefiro não dar minha opinião, vai que o negócio vire um Ext-killer?

SproutCore

O SproutCore, iniciativa da Apple, tem uma proposta um tanto “utópica”, pelo que entendi é trazer o Cocoa para a web. As demonstrações são interessantes, mas o pobre navegador sofreu as conseqüências. Esse negócio consegue ser mais pesado que a própria Ext! Além disso, vi mais opiniões negativas do que positivas…

UIZE

O UIZE (pronuncia-se “you eyes”) é outro que nunca havia sido apresentado a mim. Concordo com o pessoal do Ajaxian: são os efeitos mais legais que já vi. Apesar disso, a biblioteca ainda necessita muito mais trabalho, já que tem poucos recursos (poucos, mas legais).

Não tive a oportunidade de trabalhar por algum tempo com nenhuma dessas bibliotecas, e nem falar muito sobre as quais tenho mais experiência. Somente uma breve opinião sobre cada uma. Caso tenha esquecido de alguma, por favor, cite-a nos comentários, terei prazer em falar um pouquinho. Só uma precaução: cuidado onde você irá usar tudo isso… Existem aplicações e aplicações. Até mais!

Posts Relacionados

• Mootools vs. jQuery
• Estendendo o JavaScript
• Histórico para Navegação via JavaScript
• Estatísticas para Navegação via JavaScript
• jQuery – Segundas Impressões

Antes de tudo, nem pensem os usuários de Mootools que sou um traidor, um subversor, nem os usuários de jQuery achem que sou um “fiel convertido” e abandonarei a Mootools para todo o sempre. Ambos dois lados de acordo e em paz, vamos à comparação.

Propósito

A primeira coisa que me fez dar uma segunda chance ao jQuery foi minha maturidade adquirida de uns tempos pra cá. Pude perceber que jQuery e Mootools têm propósitos diferentes. Pode-se usá-las para a mesma coisa, mas mais código terá que ser escrito.

A Mootools é uma biblioteca bem mais complexa e mais completa. Seu escopo é bem maior, e permite muito mais coisas. Algumas dessas coisas são a criação de classes, vários métodos para os tipos nativos da linguagem (funções para Strings, Números, Arrays), JSON, cookies, e tudo o mais que você puder imaginar através de plugins. É bem mais voltada a “programação de verdade”, ou seja, trabalhar mais com a linguagem e processamento do que seu resultado no documento.

A jQuery tem um escopo muito mais fechado: DOM. Criação e edição de objetos, seletores muito poderosos e simples, baseados em CSS e XPath e manipulação de eventos. Tudo isso integrado dentro de uma mesma função. Indo um pouco mais além, a biblioteca também inclui a criação de efeitos básicos e requisições Ajax. Ainda dentro do cifrão bombado.

DOM

Tanto Mootools quanto jQuery lutam nesse campo: DOM. Ambas também possuem a mesma função $, que vem me confundindo muito quando trabalho com uma ou outra biblioteca. Na Mootools, somente IDs. no jQuery, qualquer seletor CSS3 ou XPath. Não que a Mootools não tenha todos os seletores que jQuery, mas em uma função diferente: $$. Particularmente gostei separação, mas a versatilidade da jQuery absolutamente não me incomoda. Nessa parte, pra mim é um empate.

Ainda não tive a oportunidade de inspecionar o código da jQuery, mas posso dizer que o John Resig é um gênio: além de recuperar elementos do documento, o $ ainda os cria. E não através da criação manual de elementos e nós de texto. Você digita o HTML, e a função os cria sozinha. Adeus innerHTML… Na Mootools? Bem, acho melhor pular essa parte, vocês já devem ter percebido… jQuery na cabeça.

Quanto às outras funções, como definição e recuperação de atributos, ambas bibliotecas não deixam a desejar. A jQuery, entretanto, tem o diferencial de usar a mesma função para definição de uma ou várias propriedades, além de recuperá-las. Na Mootools, temos o get e set. Pra mim não faz diferença alguma em termos de desenvolvimento, ambas são intuitivas. Empate novamente.

No final das contas, jQuery é excepcional em tarefas de DOM, e supera, e muito, a Mootools, até por ser seu “habitat natural”.

Ajax

Ajax é outra frente de batalha em que as duas bibliotecas se enfrentam. jQuery conta com métodos extremamente simples para a tarefa, muito bons para requisições simples em aplicações pouco exigentes em relação a requisições assíncronas. Já a Mootools conta com uma classe bem mais trabalhada, mais extensa e mais flexível, principalmente para eventos.

Mesmo trabalhando com, as duas bibliotecas não o fazem para o mesmo propósito na minha opinião. A jQuery me parece melhor para requisições simples: enviar a requisição e fazer alguma coisa com a resposta. Já a Mootools trabalha com os aspectos mais “sórdidos”, como as mudanças de estado, headers, enfim. Até prefiro não falar muito sobre jQuery aqui pois não tive muito tempo com Ajax, posso ainda não ter visto algumas funcionalidades.

Efeitos

Existe algo que deixe uma aplicação mais interessante do que coisas se mexendo? Eu acho que não, mas esse não é o caso. Na jQuery, temos poucos efeitos built-in, mas me parece ser bem extensível. Já a Mootools tem uma gama enorme de transições, e podemos escolher qualquer propriedade do CSS para animar, e o melhor: ainda contamos com uma maneira muito fácil de criar novas transições. Mas a Mootools, principalmente nessa nova versão, peca em manter esses efeitos fáceis de aplicar. No jQuery, só um fadeIn ou fadeOut e presto, temos um efeito. No entanto, por mais chato que seja, ainda fico com a Mootools…

Plugins

Quando só a biblioteca sozinha não dá conta, hora de chamar os plugins. Ambas bibliotecas são extremamente extensíveis, cada uma a sua maneira. Na Mootools através da extensão das classes, no jQuery através de um “mecanismo” muito interessante, que “gruda” suas funções na função jQuery.

Mesmo sendo um fã da programação orientada a objetos e da maneira como a Mootools o usa, gostei muito mais da maneira como o jQuery faz a inclusão de plugins. Eles realmente passam a fazer parte da biblioteca. Vitória do jQuery, embora no final das contas não faça diferença alguma…

Facilidade de Uso

Nenhuma das bibliotecas tem um uso complicado. Além disso, ambas tem um foco diferente.

Talvez você já tenha notado, mas a maioria dos designers e programadores JavaScript menos experientes preferem jQuery. Não é à toa, ela é extremamente simples de ser usada. Nunca ouviu dizer que jQuery é para designers? Isso também não significa que usuários mais experientes ou experts na linguagem não irão gostar ou conseguir trabalhar.

Já a Mootools, como diz o próprio site, é direcionada a usuários intermediários ou avançados. À primeira vista ela é realmente mais complicada, sem dúvida. Talvez por isso não chame tanto a atenção quanto jQuery.

E o vencedor é…

Como disse logo no início do texto, jQuery e Mootools são bibliotecas diferentes, servindo para propósitos diferentes. Não é possível compará-las em sua totalidade, por isso não falei sobre muitos recursos que a Mootools oferece e jQuery não tem (built-in, é claro). jQuery é para DOM, Mootools é para facilitar sua programação. Já imaginou ambas bibliotecas juntas? Enfim, tenha bom senso e saiba utilizar as bibliotecas onde elas se dão bem, e não seja cabeça-dura como eu era tentando usar a Mootools em qualquer situação…

Posts Relacionados

• jQuery – Segundas Impressões
• Lançada a Mootools 1.2
• Ajax com a Mootools
• Mootools – Eventos
• Mootools – Chain

Por algum motivo de natureza desconhecida, nunca gostei muito de jQuery. Talvez eu não tenha gostado muito do $ pau-pra-toda-obra, ou então da excessiva facilidade que a biblioteca propõe. Por alguma outra razão também desconhecida, há alguns dias atrás resolvi dar uma segunda olhada na biblioteca-prodígio. Se tem tanta gente usando, algo de bom deve ter.

Durante os Testes

Depois alguns minutos testando a biblioteca direto no Firebug, tive a mesma impressão do que na última vez em que a usei: cada função, cada método faz no mínimo umas três coisas diferentes. Definir um atributo, recuperar seu valor, definir vários atributos ao mesmo tempo e ainda pode servir um cafezinho. Talvez esse tenha sido um dos motivos para me afastar da biblioteca. A diferença é que de uns tempos pra cá venho aumentando bastante minha maturidade na programação, e vi que esse conceito pode servir muito bem. Ponto pro jQuery.

Outra característica que não me agradou muito na primeira experiência com jQuery é o retorno da função $: ela sempre retorna um objeto jQuery, e não o objeto DOM que eu escolhi. Isso, na época, me incomodou muito. E se, na pressa, eu quiser jogar um innerHTML e não quiser me preocupar com criar e injetar nós? Mais uma estupidez minha, o método html cuida de tudo isso, e nunca mais vou precisar me preocupar em criar nós… Além do mais, acabei descobrindo que não estender objetos nativos é bem melhor em questões de performance. Mais um ponto pro cifrão polivalente.

Durante a Produção

Hora de passar para a prática. Como qualquer outra nova ferramenta, é complicado usar jQuery quando se está acostumado à Mootools. Estou me atrapalhando bastante, principalmente na hora de usar os seletores. Já cansei de usar $$, esquecer o # antes de IDs, trocar nomes de métodos, enfim. Tudo normal, eu pego o jeito…

Esquecendo a questão da produtividade em período de adaptação, fiquei bastante satisfeito com a biblioteca. No que ela se propõe a fazer, é simplesmente fenomenal, algo fora de série. Versátil, simples e poderosa. Gostei muito dos métodos relacionados a Ajax que, para qualquer requisição simples, são úteis e otimizados ao extremo em termos de código.

E a escolha?

Gostei de jQuery, muito. Acredite, se você nunca usou, não sabe o que está perdendo, e se já usou e não gostou antes de testar mais aprofundadamente, não seja cabeça-dura como eu e dê outra chance. John Resig, o criador da jQuery, com certeza sabia o que estava fazendo, até porque ele é o cara!

Mas e a Mootools, onde fica nessa história? Não vou abandoná-la, ainda é minha biblioteca preferida. Ela é imbatível em características que o jQuery não tem. Ambos servem para propósitos diferentes. Não vou “escolher” alguma das duas, o ideal é unir o potencial de ambas, não sou xiita.

Essa experiência serviu para me mostrar que uma ferramenta não pode resolver todos os seus problemas de maneira eficiente, mas podemos unir várias ferramentas para resolver vários problemas da melhor maneira possível. Aguardem os próximos capítulos dessa história…

Posts Relacionados

• Mootools vs. jQuery
• Interfaces de Usuário com JavaScript
• Ajax com a Mootools
• Escolhendo o Framework Certo
• Lançada a Mootools 1.2

Como acabei precisando de um scroller assim, aproveitei e criei uma classe que poderei reutilizar em algum outro projeto em que ela se faça necessária. Já que gostei do resultado, vou aproveitar e deixar o script pra vocês. O resultado será algo parecido com esse exemplo. Prontos? Então vamos lá!

O Código

O script não poderia ser mais simples, em torno de umas 50 linhas de código (você precisaria de centenas se não fosse a Mootools, ou alguma outra biblioteca que faça o serviço sujo). Você pode fazer o download dele aqui. Para “instalá-lo”, basta incluí-lo em seu documento, assim como a Mootools. Além disso, você também vai precisar do plugin Fx.Scroll, que pode ser conseguido no More Builder da Mootools, e incluí-lo no seu documento também.

Update: logo que precisei usar a classe novamente, vi que cometi um erro grotesco. Código atualizado, com erro corrigido e uma nova funcionalidade, explicada logo abaixo. Valendo uma mariola pra quem descobrir minha estupidez, os dois códigos estão disponíveis para download.

O HTML

O HTML necessário é a parte que eu considero a mais complicada, chata e sem graça. Sem o HTML criado direitinho, o scroller não vai funcionar. A lógica é a seguinte: precisamos de um container (geralmente uma div) de uma largura (ou altura) fixa. Esse container é quem vai esconder os itens que não serão mostrados no scroller. Dentro desse container, vamos precisar de mais um container (geralmente mais uma div, ou então uma lista), também de altura/largura fixa, mas que seja igual a toda a extensão dos itens. Ou seja, o container de dentro será maior do que o container de fora.

<div id="container">
    <div></div>
</div>

Acredite, é mais complicado do que parece. Agora sim, podemos colocar nossos itens dentro do container que está dentro de outro container (hein?). Fora isso, precisamos apenas de mais dois elementos (podem ser links) para serem os handlers de anterior e próximo e pronto, aí está o HTML. Só precisamos do CSS que vai ajudar na mágica do script.

O CSS

Como o nosso container externo precisa esconder o que há no container interno (que é maior), ele precisará de um overflow: hidden. Sem isso, tudo o que há no container interno ficará exposto, e aí o scroller perde a graça. Também não podemos nos esquecer de definir as alturas/larguras dos containers e itens. Vamos fazer primeiro um scroller vertical, ligeiramente mais fácil:

* {
  margin: 0;
  padding: 0;
}
#container {
  height: 20px;
  overflow: hidden;
  width: 100px;
}
#container div {
  /* Não é necessário definir a altura, o elemento irá "crescer" sozinho */
  width: 100px;
}
#container p {
  /* A mesma altura de #container, mas isso pode variar com o gosto do freguês */
  height: 20px;
}

O Script

Agora sim, vamos colocar a mão na massa. Minha classe, quando instanciada, leva apenas dois parâmetros: o container exterior (o container interior é deduzível…) e as opções. Dentre elas, temos à disposição todas as opções da classe Fx, e também previousButton e nextButton, que são os handlers para o elemento anterior e posterior do scroller.

var myScroller = new Fx.Scroller("container", { previousButton: "previous", nextButton: "next" })

Aproveitando a atualização da classe, também criei vergonha na cara e adicionei os eventos onNext e onPrevious, executados quando o scroller vai para frente ou para trás, respectivamente.

Pronto! Você escreveu apenas uma linha de script e seu scroller já está funcional, passando de um elemento para outro com apenas um clique!

Scrollers Horizontais

A termos de script, um scroller horizontal é idêntico. A mágica se esconde toda no CSS para este caso. Primeiro precisamos colocar os elementos um ao lado do outro dentro do container interior, certo? Certo. Para isso, usamos a propriedade float, sinta-se à vontade para escolher a qual lado flutuar.

Passando ao segundo passo, devemos definir a largura. A fórmula é a seguinte: número de elementos vezes a largura de qualquer um deles. Se você usar margins ou paddings, não esqueça de levá-los em consideração também.

Usando a técnica de scrollers horizontais, também podemos criar scrollers “mistos”. Nesse caso, há várias linhas e várias colunas de itens ao mesmo tempo. O efeito, se bem usado, pode ficar muito interessante. Quem teve a oportunidade de observar os demos da versão 1.1 da Mootools deve saber do que estou falando.

Dicas para Ir Além

Bem, só fazer itens se mexerem pode não ter tanta graça assim pra você. Como eu disse, minha classe usa todas as opções da classe Fx, ou seja, eventos, transições, offsets, enfim. Agora é sua vez de brincar! Use o offset para mudar a posição dos itens, eventos para mudar sua opacidade, criatividade! Também sinta-se livre para usar os métodos da classe também: next, previous, scrollTo, enable e disable (para ativar ou desativar os botões).

Espero que isso sirva pra alguma coisa! E também espero postar em um intervalo um pouco menor… O pessoal deve ter pensado que eu fugi do país depois de uma certa polêmica. Mas não, só estive ocupado mesmo… Até mais!

Posts Relacionados

• Mootools – Chain
• Mootools – Eventos
• Mootools – Options
• Sliders com Mootools
• Mootools – Menu Sanfona

Dentre as novidades, podemos citar o Swiff (plugin para integração com Flash), Element Storage, entre várias outras, como foi anunciado na versão beta (que eu não testei, diga-se de passagem).

Pelo visto, mais coisas interessantes para descobrir nessa biblioteca que eu acho simplesmente incrível, e agora facilitando nossas vidas como nunca! Vai lá, faça o download, teste, e garanto que você vai gostar!

Posts Relacionados

• Scroller Made in Mootools
• Ajax com a Mootools
• Mootools vs. jQuery
• Mootools – Classes
• Mootools – Options

O Slider

Antes de começarmos a brincar com os controles de rolagem postos em nossas páginas, devemos antes criar a estrutura do HTML. Precisamos de dois elementos: um slider (o container) e um knob (o controle). Vamos usar duas divs aninhadas:

<div id="slider">
  <div id="knob"></div>
</div>

Logicamente, também devemos estilizar esses elementos, para que eles se pareçam, mesmo que remotamente, com um slider. Eu optei pela configuração mais simples possível:

#slider{
  background: #000;
  width: 200px;
}
#knob {
  background: #f00;
  width: 20px;
}

Pronto! Ele já está lá, não se movendo de jeito algum, mas está lá.

Movendo o Controle

Para que possamos mover o dito cujo, vamos instanciar a classe Slider, que faz todo o trabalho sujo para nós. Essa classe recebe três parâmetros: o container, o controle e as opções para o slider. Como queremos um simples slider comum e sem graça (por enquanto), vamos omitir o terceiro parâmetro.

var slider = new Slider("slider", "knob")

Difícil, não? Já temos um slider funcional! Aliás, quase funcional, ele não faz mais nada além de se mover. De que adianta um slider que só se move, e não retorna sua posição? Calma, chegaremos lá.

Adicionando Funcionalidade

Através da opção onChange, podemos fazer algo com a posição do slider. Pode-se atualizar um campo com a posição atual, mudar o tamanho/posição de alguma coisa na tela, enfim, não sou muito criativo, você pode ir bem mais longe que isso.

Para essa opção, devemos passar uma função que receberá como parâmetro a posição atual do slider. A partir disso, podemos fazer qualquer coisa com ele. Veja:

var slider = new Slider("slider", "knob", {
  "onChange": function(pos) {
    $("div-qualquer").setHTML("Posição do Slider: " + pos)
  }
})

É lógico que esse é o uso mais simplório possível. Fiz algo nem tão sem graça assim, veja nos exemplos. Aumenta fonte, diminui fonte… Dá pra fazer mais que isso sim, e muito.

Outras Opções

A Mootools também nos deixa mais algumas opções para incrementarmos nosso slider. São elas:

• steps: Indica o número de “steps” que o slider terá. Por padrão é setado como 100.
• mode: “vertical” ou “horizontal”. Define o modo do slider.
• offset: Recuo do controle em relação ao container.
• onComplete: função a ser executada quando o controle for soltado. Não recebe parâmetros, então é necessário usar o método getPos caso seja necessário utilizar a posição.

Ficou feio?

Aqui apliquei somente o estilo básico para o slider funcionar. Você pode se divertir com CSS, e torná-lo muito mais atraente. Nos exemplos mostrei meus estupendos talentos em design e criei algo mais interessante aos olhos do usuário.

Vou ficando por aqui, até mais!

Posts Relacionados

• Mootools – Options
• Ajax com a Mootools
• Scroller Made in Mootools
• Mootools – Menu Sanfona
• Mootools – Chain

O HTML

Antes de começar com o comportamento, primeiro vamos criar o conteúdo do menu. Uma lista simples, com outras listas aninhadas, as quais
ficarão escondidas até que seus títulos sejam clicados.

<ul>
        <li><h3>Título 1</h3>
                <ul>
                        <li>Item 1</li>
                        <li>Item 2</li>
                        <li>Item 3</li>
                </ul>
        </li>
        <li><h3>Título 2</h3>
                <ul>
                        <li>Item 1</li>
                        <li>Item 2</li>
                        <li>Item 3</li>
                </ul>
        </li>
</ul>

Nada em especial até agora, mas temos que incluir mais alguns atributos aí. Para que a Mootools possa identificar quais itens serão clicáveis e quais deverão ficar “escondidos”, precisamos identificá-los com classes. Não há restrição para alguma classe específica, mas costumo usar toggler para os clicáveis e element para os itens escondidos.

<ul>
        <li><h3 class="toggler">Título 1</h3>
                <ul class="element">
                        <li>Item 1</li>
                        <li>Item 2</li>
                        <li>Item 3</li>
                </ul>
        </li>
        <li><h3 class="toggler">Título 2</h3>
                <ul class="element">
                        <li>Item 1</li>
                        <li>Item 2</li>
                        <li>Item 3</li>
                </ul>
        </li>
</ul>

O Script

Agora sim, a parte difícil, ou nem tanto assim. Como tudo na Mootools é baseado em classes, o menu sanfona não foge à regra. A classe Accordion é a responsável por todo o menu, desde identificar seus elementos até mostrar/esconder o conteúdo.

window.addEvent('domready', function() {
	var accordion = new Accordion('h3.toggler', 'ul.element')
})

Como parâmetros, passamos os títulos clicáveis e o conteúdo de cada item, somente isso. A biblioteca cuida do resto. Difícil, não?

Algumas Opções

Podemos ir um pouco além do básico, e adicionar alguma personalização em nosso menu. Para isso, a classe nos dá algumas opções. Basta passar um objeto como terceiro parâmetro. As opções possíveis são:

• show: índice do elemento a ser mostrado inicialmente
• display: índice do elemento a ser mostrado inicialmente. Diferentemente de show, esse elemento será mostrado com uma transição
• fixedHeight: altura fixa dos itens, padrão false
• fixedWidth: largura fixa dos itens, padrão false
• height: inclui transição de altura, padrão true
• opacity: inclui transição de opacidade, padrão true
• width: inclui transição de largura, padrão false
• alwaysHide: permite esconder todos elementos, em vez de manter ao menos um sendo mostrado, padrão false

Além das opções, temos também dois eventos:

• onActive: executado quando algum item se tornar ativo
• onBackground: executado quando algum item for escondido

Finalizando

Agora vamos modificar um pouco nosso menu, utilizando as opções e eventos vistos acima.

window.addEvent('domready', function() {
	var accordion = new Accordion('h3.toggler', 'ul.element', {
		"opacity": false,
		"onActive": function(toggler) {
			toggler.setStyle("color", "#f00");
			toggler.setStyle("font-weight", "bold");
		},
		"onBackground": function(toggler) {
			toggler.setStyle("color", "#000");
			toggler.setStyle("font-weight", "normal");
		}
	})
})

Pronto! Veja o exemplo finalizado. E mais: retirando todas as transições, você tem um menu sanfona totalmente customizável. O poder e a facilidade da Mootools. Incrível, muito bem pensado, por isso adoro essa biblioteca. Até mais!

Posts Relacionados

• Mootools – Options
• Lançada a Mootools 1.2
• Ajax com a Mootools
• Sliders com Mootools
• Scroller Made in Mootools

Propriedades Estáticas

Propriedades e métodos estáticos são aqueles que podem ser acessados de qualquer lugar do script, sem a necessidade de instanciar a classe. Considera-se que o JavaScript não suporta esse conceito, já que não possui classes, mas pode-se também simular.

Funções não deixam de ser objetos, e objetos podem ter propriedades. Veja no exemplo:

function Person() {  }
        Person.staticMethod = function() { alert("Método Estático"); }
        Person.staticMethod(): // "Método Estático"
        var me = new Person();
        me.staticMethod(); // Retornará erro

Também muito simples, e bem útil em certas ocasiões. Podemos tomar como exemplo a Mootools, com o Class e Class.empty. Class é um construtor, e Class.empty é um método estático.

Herança

A herança é outro conceito que o JavaScript não implementa formalmente, necessitando das famosas gambiarras. Quando bem empregada, permite uma grande reutilização de código, criando classes derivadas a partir de uma superclasse (classe-mãe), herdando todas as propriedades.

Existem vários tipos específicos de pessoas, em vários sentidos. Brasileiros, portugueses, americanos, vendedores, médicos, desenvolvedores… Mesmo sendo mais específicos, todos eles têm características comuns de uma pessoa. Assim, o construtor Brazilian é derivado de Person.

Primeiro, vamos criar os construtores com suas propriedades.

function Person() {
                this.eyes = 2;
                this.speak = function(message) {
                        alert(message);
                }
        }
        function Brazilian() {
                this.birthCountry = "Brasil";
        }

Pessoas falam, e isso se aplica também aos brasileiros, mas nem todas as pessoas nasceram no Brasil. Assim, a superclasse (ou super-construtor) é Person, e somente nela definimos as propriedades comuns.

Para fazer a herança existem vários métodos, mas vou explicar agora somente o que considero o mais simples e usado. Basta criar uma instância do “super-construtor” no protótipo do construtor derivado, assim:

Brazilian.prototype = new Person;

Todo o construtor Person foi instanciado como parte de Brazilian. Agora podemos criar um objeto Brazilian e utilizar tanto as propriedades específicas (definidas no próprio construtor) quanto as do “super-construtor”.

var me = new Brazilian("Julio Greff");
        alert(me.birthCountry); // "Brasil"
        me.speak("Olá!"); // "Olá!"

Existem outros métodos para herança, mas como já disse ficarão para outra oportunidade. E a série sobre JavaScript Orientado a Objetos se encerra aqui! Qualquer correção ou sugestão será bem vinda, basta comentar! Até!

Posts Relacionados

• JavaScript Orientado a Objetos – Parte 2
• JavaScript Orientado a Objetos – Parte 1
• PHP Orientado a Objeto
• Estendendo Objetos DOM
• Estendendo o JavaScript

A Propriedade prototype

No JavaScript, toda função construtora possui uma propriedade chamada Function.prototype. Essa propriedade nos permite adicionar e, em certos casos modificar, propriedades ou métodos de um construtor, após sua definição. Diferente de PHP, por exemplo, podemos adicionar propriedades durante a execução.

function Person() {}
        var me = new Person();
        alert(me.eyes); // undefined
        Person.prototype.eyes = 2;
        alert(me.eyes); // 2

Como se pode notar, na primeira tentativa não tínhamos a propriedade definida. Após isso, adicionada em tempo de execução, já temos a propriedade definida.

Também há certas exceções na utilidade do Function.prototype. A primeira delas é que essa propriedade não consegue sobrescrever qualquer coisa que já tenha sido definida no construtor. Não podemos definir uma propriedade no construtor e depois mudar seu valor através de Function.prototype.

function Person() { this.eyes = 2; }
        var me = new Person();
        alert(me.eyes); // 2
        Person.prototype.eyes = 1;
        alert(me.eyes); // 2, continuo tendo 2 olhos

Para resolver esse problema e continuar usando Function.prototype, podemos definir a propriedade fora do construtor usando a técnica, e sobrescrevê-la da mesma maneira.

function Person() {}
        Person.prototype.eyes = 2;
        var me = new Person();
        alert(me.eyes); // 2
        Person.prototype.eyes = 1;
        alert(me.eyes); // 1

Outro pequeno problema é quando definimos objetos ou arrays através dessa propriedade. Veja:

function Person() {}
        Person.prototype.uses = ["watch", "glasses"];
        var me = new Person();
        var you = new Person();
        me.uses.push("hat");
        alert(me.uses); // ["watch", "glasses", "hat"]
        alert(you.uses); // ["watch", "glasses", "hat"]

Com base no exemplo, pode-se ver que o array é compartilhado, assim como todos os seus itens. Moral da história: é preferível definir tudo no próprio construtor, ou então definir apenas métodos através de Function.prototype.

Encapsulamento

Formalmente, encapsulamento ainda não existe no JavaScript, mas podemos usar esse recurso disfarçado.

Tudo o que criamos dentro de nossos construtores está no escopo público, ou seja, pode ser acessado de dentro do construtor ou do restante do script. Uma maneira de simular variáveis privadas, que só podem ser acessadas de dentro do construtor e por seus métodos, é utilizando o escopo local. Lembra-se de quando falei sobre escopo de variáveis?

function Person() {
                this.public = "Variável Pública";
                var private = "Variável Privada";
                this.publicMethod = function() {
                        alert(this.public);
                        alert(private);
                }
                var privateMethod = function() {
                        alert(private);
                }
                this.callPrivate = function() {
                        alert(private);
                }
        }
        var me = new Person();
        alert(me.public); // "Variável Pública";
        alert(me.private); // undefined
        me.publicMethod();
        me.privateMethod(); // Retornará erro
        me.callPrivate();

O exemplo acima exemplifica bem de onde cada tipo de variável pode ser acessado. Já o uso de variáveis protegidas (protected) necessitam de mais gambiarras, mas isso fica pra outra vez.

Quanto ao uso de métodos privados só existe um pequeno problema: não é possível acessar propriedades ou métodos públicos diretamente. Para isso, é necessário modificar o escopo em que a função executada, através de Function.bind (função user-defined).

function Person() {
                this.public = "Variável Pública";
                var bindPublic = function() {
                        alert(this.public);
                }.bind(this);
                bindPublic();
        }
        var me = new Person();

Para testar, lembre-se de copiar a função Function.bind!

E a parte 2 se encerra aqui. Volto na parte 3 pra falar mais um pouco sobre programação orientada a objetos. Até lá!

Posts Relacionados

• JavaScript Orientado a Objetos – Parte 3
• JavaScript Orientado a Objetos – Parte 1
• PHP Orientado a Objeto
• As Vantagens de Prototype
• Estendendo Objetos DOM

Depois de muito tempo, resolvi editar essa série e repostá-la aqui. Aprendi um pouco mais sobre o assunto através da prática, corrigi alguns erros – muito criticados na época – e adicionei algumas informações que achei pertinentes. Como dá pra ver, o permalink continua o mesmo, e a versão antiga da série já não está mais no ar. Espero que as correções e adições possam esclarecer bem o assunto.

Alguns Conceitos

Antes de começarmos a colocar as mãos em código, vamos aprender um pouco de teoria. O JavaScript não é uma linguagem orientada a objetos completamente desenvolvida, e não implementa alguns conceitos nativamente, como herança e variáveis públicas e privadas, dependendo de “gambiarras” para sua implementação.

A base da programação orientada a objetos é, logicamente, objetos. Um objeto é uma abstração de algo real (uma mesa, um carro, a janela do navegador, um elemento HTML…). Esse objeto possui sua própria estrutura de dados, encapsulada em seu próprio escopo. Esses dados podem ser tipos primitivos (Strings, Arrays, Numbers, Booleans…), funções (as quais chamaremos de métodos, quando dentro dos objetos) e até outros objetos.

Para criarmos um objeto, precisamos da definição de sua estrutura de dados, criada através de uma matriz. Essa matriz é chamada de classe, ou construtor no JavaScript.

De começo creio que é o suficiente. Quando for necessário, explicarei outros conceitos, como encapsulamento, polimorfismo, herança…

Criando Construtores

Em nosso querido JavaScript, um construtor é apenas uma função comum, que é instanciada em uma variável. Essa instância se faz através da palavra-chave new, indicando a criação de um novo objeto.

function Person() {}
	var me = new Person();

A palavra-chave new, entretanto, só é necessária caso quando a função não retorna o objeto recém-criado. Para retorná-lo, usamos a palavra-chave this.

function Person() { return this; }
	var me = Person();

O this, apesar de estar no construtor, refere-se ao próprio objeto. Ele será bem usado mais a frente.

Definindo Propriedades

Propriedades, ou atributos, são os dados que ficam encapsulados no escopo do objeto. Como dito mais acima, essas propriedades podem ser tipos primitivos, funções ou outros objetos.

Seguindo a idéia de algo real, toda pessoa tem um nome. Vamos dar um nome à pessoa que “criamos”.

var me = new Person();
	me.name = "Julio Greff";

No código acima, definimos um nome apenas ao objeto me. Outros objetos criados a partir de Person não terão a mesma propriedade. Isso é útil em nosso caso, já que somente eu me chamo “Julio Greff”, e só você possui seu nome.

A mesma técnica não é tão útil quando precisamos definir uma propriedade para todos os objetos criados a partir de determinado construtor. Já pensou se tivéssemos, por exemplo, que definir o número de olhos para cada pessoa que criarmos? Para evitar retrabalho, definimos as propriedades comuns a todos objetos dentro do construtor.

function Person() {
		this.eyes = 2;
	}

No exemplo, usei this para me referir ao próprio objeto, ou seja, todo objeto criado terá a propriedade eyes igual a 2.

Mesmo definindo uma propriedade comum a todos objetos, podemos modificar alguma propriedade de um objeto em particular sem que os outros sejam afetados. Por exemplo, no caso de um cíclope, caolho ou alguma anomalia genética grave.

var me = new Person();
	var cyclop = new Person();
	cyclop.eyes = 1;
	alert(cyclop.eyes); // 1
	alert(me.eyes); // 2, inalterado

Como você deve ter notado – ou pelo menos devia – o acesso às propriedades é feito através do . (ponto), assim como é feita a sua definição.

Desde quando a humanidade é a humanidade, toda pessoa recebe um nome quando nasce. Também pode receber um apelido, uma roupa, ou qualquer outra coisa. Com os objetos acontece algo parecido. Na “concepção” de cada objeto, podemos passar parâmetros para a função construtora, assim como faríamos como outra função qualquer. Esses parâmetros podem, mais tarde, vir a se tornarem propriedades do objeto.

function Person(name) {
		this.name = name;
	}

Dessa maneira, quando criamos o objeto, já podemos dar um nome à pessoa, sem a necessidade de fazê-lo depois da criação do objeto.

Definindo Métodos

Assim como características (propriedades), pessoas também têm comportamento: andar, falar, comer… Objetos também têm comportamento, e esses comportamentos são chamados de métodos. Métodos nada mais são do que funções que são executadas no escopo de algum objeto.

Para criarmos métodos, procedemos da mesma forma com que criamos propriedades. Simples, rápido e indolor:

function Person() {
		this.speak = function(message) {
			alert(message);
		}
	}

Para executarmos métodos também procedemos da mesma forma com que acessamos propriedades, com a diferença de que estamos chamando uma função.

me.speak("Olá!"); // "Olá!"

Essa não é a única maneira de criar métodos, mas é a mais simples, mais organizada e mais eficiente. As outras formas usam propriedades apontando para uma função criada normalmente, dentro ou fora do objeto.

Para a parte 1 é o suficiente. Tenha uma boa digestão e logo volto com mais! Até lá!

Posts Relacionados

• JavaScript Orientado a Objetos – Parte 3
• JavaScript Orientado a Objetos – Parte 2
• PHP Orientado a Objeto
• Estendendo Objetos DOM
• Estendendo o JavaScript