Nosso primeiro plugin - ActsAsModerated

Propaganda Gratuita :lol:

Opa galera, acabei de "remover" o primeiro plugin de uma aplicação Rails aqui, o ActsAsModerated -> http://blog.codevader.com/2008/04/30/our-first-rails-plugin-actsasmoderated/

O plugin é bem simples, ele funciona como uma fila de itens em moderação, pra usar basta instalar o plugin gerar o migration dele e colocar isso no seu modelo:

class Noticia acts_as_moderated end

E pra colocar uma alteração em moderação:

E um objeto Moderation é criado contendo as alterações desse objeto (o objeto em si não é salvo, claro). Vejam o gem e a aplicação de exemplo que vem com ele :slight_smile:

Não foi um negócio complicado de se fazer, mas o aprendizado em se criar um plugin pro Rails foi bem interessante (se bem que o plugin é pro ActiveRecord, não pro Rails em si).

Uma coisa interessante esse ecossistema de plugins do Rails. Não tem nada demais mas esses ‘act_as’ da vida suprem uma reusabilidade que há muito é prometida e nunca se cumpriu. Ninuém importaria um JAR enm que tivesse 5k só para fazer isso mas o modelo de deployment do Rails/Ruby muda um pouco o mindset. Ou não?

Muda. O custo de testar um plugin desses numa app Rails eh muito baixo - se der errado, eh soh arrancar do /vendor/plugins e pronto.

Então se Java tivese um apt-like/rugyforge default teria esse ecossistema?

Rapaz, eu acho muito difícil de que um simples apt/gem da vida resolvesse o problema.

Acho que o buraco é bem mais embaixo :slight_smile: (tá saindo um post sobre isso nesses próximos dias, anyway).

Adicionar extensões em uma classe Java é uma tarefa hercúlea. Claro que você pode simplesmente partir pra um modo usando CGLIB ou outra biblioteca de reflexão mas primeiro que todo o código do cliente vai ter que ser gerenciado por isso, então nada de new no seu objeto (o que é uma bela porcaria pra objetos de negócio). Então você fica com duas opções factíveis, um pós-compilador que adiciona a funcionalidade com base em algum metadado (annotations por exemplo) ou usa uma ferramenta de AOP de tempo de compilação como o AspectJ. O pós-compilador fica fora de cogitação pelo simples fato de que a IDE não vai deixar você chamar um método que não está definido na sua classe (como o to_moderation no meu caso, que vem de um mixin), então sobra só o AspectJ, mas usando o AspectJ você assume que o cliente do seu código vai ter que compilar tudo usando o AspectJ, o que nem sempre é possível, então aqui já estamos fora.

Outro problema que é ainda mais sério, é que os frameworks dificilmente tem uma boa arquitetura pra a adição de plugins ou simplesmente escondem essas coisas. Um exemplo clássico é o Hibernate, não há nem um capítulo no Java Persistence with Hibernate (ou no antigo Hibernate In Action) sobre como você pode adicionar novas funcionalidades ou incluir novas coisas na ferramenta e a documentação desses troços é pífia, você tem que sair fuçando nos códigos do Hibernate pra ver se entende aonde a sua funcionalidade deveria ser adicionada. JPA é um exemplo que chega a beirar o ridículo, pois não existe nem um padrão pra se definir novos tipos persistíveis (e eu acho que isso é o básico do básico, quem aí ainda não teve que persistir objetos especiais como Telefone o Dinheiro?), eu acho até que ali não tem personalização é de nada, toda a personalização tem que ser feita no próprio framework que você está usando.

Enfim, a linguagem torna complicado e os frameworks utilizados comumente também não ajudam de forma alguma, então criar um mesmo ecossistema pra Java é meio que tomar os 12 trabalhos de Hércules pra fazer.