Aug 23 2012

Desenvolvendo o Cryml

Primeiramente, este é um artigo escrito por Dalton Pinto no blog do Flavio Muniz. Agradeço pelo espaço já que me coloquei a restrição de só começar o meu próprio blog depois que houver terminado de concluir a primeira versão estável do Cryml, e fazê-lo com o mesmo. Valeu Flávio!

Por causa da RubyConf Brasil 2012, varias pessoas vieram me perguntar sobre o projeto que venho desenvolvendo à alguns meses, o Cryml.

Devido o fato de eu ser extremamente chato quanto à código inacabado, não divulguei publicamente o código, e coloquei como marco o próprio evento para divulgar o projeto, e aproveitar também para gerar expectativa. Para os mais curiosos, deixo aqui neste artigo uma prévia do que estarei palestrando na RubyConf 2012.

Motivação

Atualmente, podemos notar que há uma tendência e necessidade natural das linguagens de markup em se aproximarem de linguagens de programação.

Esse fato é totalmente compreensível se levarmos em conta que quando o HTML surgiu, não existiam páginas dinâmicas, e ele funcionava mais como um formato de arquivo a ser transferido via browsers.

Assim a Web evoluiu de tal forma que as interações do browser se tornaram bem mais complexas e poderosas do que apenas uma transferência e exibição de arquivos.

A maneira mais tradicional e imediata é montar esses arquivos a partir de templating systems que basicamente funcionam como “fill in the blanks” com esteróides para injetar e adicionar dinamismo. É exatamente isso que faz o ERB.

Outra solução que vale a pena ser levada em consideração é o HAML, que se propõe a criar um HTML baseando-se numa sintaxe própria que já é “HTML Aware” e se integra de maneira menos alienígena ao código Ruby. Digo isso mesmo não gostando da sintaxe do mesmo, que para mim soa como um tentativa críptica de comprimir um HTML.

Porém algo que me chama e muito a atenção é o DRYML, parte do HOBO, que apesar de pouco usado me parece uma solução extremamente inteligente. De forma simplista, a idéia é escrever um HTML com tags definidas pelo usuário, como se fosse uma extensão natural do próprio HTML.

Inspiração

O conceito do DRYML não é novo, ele é bem semelhante ao conceito de taglibs em Java para criação de tags customizadas, na qual cada tag funciona como uma função com parâmetros nomeados e um bloco (lembra algo não?).

Assim nasceu a idéia do Cryml, inicialmente ele se propunha a ser apenas uma implementação em C do Dryml. Isso foi motivado pela minha primeira tentativa de usá-lo num projeto Sinatra, onde me deparei com o seguinte problema:

O método que deveria ser usado para utiliza-lo fora do Rails, simplesmente possui diversas dependências do Rails o.O.

Mudança de Rumo

Ao longo do processo de desenvolvimento, me deparei com diversos detalhes que me fizeram a repensar o Cryml, e isso resultou numa guinada total no rumo do projeto.

Isso ocorreu quando notei uma chateação simples na sintaxe, imposta pelo fato de que o Dryml interpreta um HTML modificado e o suporte a atributos que não contenham apenas strings, mas sim conteúdos a serem interpretados.

Neste instante decidi abandonar a exigência de ser apenas um HTML com tags customizadas, e resolvi escrever um parser permitindo uma sintaxe alternativa para os atributos. Neste instante abandonei o libxml e parti pra uma solução se valendo de flex/bison.

Deste instante em diante, comecei a ter a preocupação de criar algo que continuasse simples e intuitivo de ser usado pelos desenvolvedores, mas que por baixo dos panos fosse o mais robusto e extensível possível, resolvendo problemas que muitas vezes nos passam despercebidos, mas que em sua essência surgem de detalhes sutís.

Alguns dos pontos que tornam o Cryml diferente dos demais estão listados a seguir.

O Cryml se Propõe a:

• ser consciente quanto aos dados: diferentemente do ERB, HAML e Dryml, o Cryml permite uma integração natural dos dados, sem necessidade de ter que recorrer a alternativas como duplicação de variáveis de instância.
• ser consciente quanto ao layout: não é apenas ter chamadas de render de partials ou ter um yield no meio, mas sim ser ciente quanto a existência de layouts, permitindo uma solução mais inteligente quanto ao uso de artifícios como o content_for do Rails.
• ser agnostíco quanto a linguagem de programação: os templates podem ser completamente independentes de linguagem de programação, ainda assim se integrando com as linguagens dos frameworks utilizados, permitindo assim migrações de frameworks, ou mesmo num futuro, a migração de todo o processo de rendering para o browser. Isso é possível graças a implementação do Cryml que permite encapsular objetos externos e tratá-los como se fossem parte de suas estruturas de dados nativas, evitando-se que seja necessário escrever código / injetar via placeholders.
• ser adequado para streaming: o Cryml é uma biblioteca sobre a qual linguagens de programação poderão ser integradas via streams, permitindo que sejam usadas para enviar dados a medida que são criados, economizando memória e permitindo que browsers como o Webkit baixem seus arquivos de javascript e css em paralelo.
• ser inteligente quanto ao aproveitamento do parsing: esse é um detalhe interessante que pretendo explorar durante a RubyConf, e por sí só já poderia render um artigo inteiro sobre o tema.
• comprimir o arquivo resultante: o simples fato de ser consciente quanto ao formato HTML, permite que seja facilmente comprimível o HTML gerado, sem grandes esforços, com ganho de desempenho.

Ok, mas eu quero um exemplo!

Ok, justo. Um pequeno showdown:

ERB:

<% if @user_logged_in %>
  <%= @user_name %> logged
<% else %>
  <a href="<%= sign_in_path %>">Sign In</a>
<% end %>
<ul>
  <% @friends.each do |friend| %>
    <li><%= friend %></li>
    <% if @user_logged_in %>
      <a href="<%= create_friendship_path friend %>">Add <%= friend %> as friend</a>
    <% end %>
  <% end %>
</ul>

Cryml:

<if is=$user_logged_in>
  <then put=$user_name/> logged
  <else><a href=sign_in_path()>Sign In</a></else>
  <ul>
    <each attr='friend' in=$friends>
      <li><@friend/></li>
      <then>
        <a href=create_friendship_path(@friend)>Add <@friend/> as friend</a>
      </then>
    </each>
  </ul>
</if>

Neste exemplo, eu mostro o uso de tags if, then, else e each simples, que substituem as chamadas de código Ruby.

Apesar da sintaxe semelhante, os “@” e “$” em nada remetem a chamadas Ruby, os prefixos $ representam os dados passados para o rendering, já os @ representam os atributos gerados através da interpretação das tags.

Logo que a documentação estiver pronta, tudo fará mais sentido, o intuito desse artigo é dar uma prévia de quais os desafios que o Cryml se propoe a enfrentar, ainda assim sem se parecer algo estranho para o desenvolvedor.

Aguarde na RubyConf…

Além de lançar o código fonte, explicarei melhor alguns detalhes que não tratei aqui e mostrarei mais exemplos, me reservo a dizer que um impressionará.

Dalton Pinto
@dalthon

By flaviomuniz • Cryml, haml, html, Ruby Conf, ruby on rails • 0 • Tags: cryml, ruby, rubyconf