Merlin para web com GWT

Primeiro, a imagem:

Agora, o texto:

Desde que troquei as minhas funções diárias de arquiteto de soluções por gerente de projetos, meu tempo disponível para projetar e implementar de aplicações e frameworks praticamente desapareceu.

Houve épocas que fiquei mais de mes sem abrir o meu (inchado de plugins) Eclipse. Uma dor.

Mas ei que a vontade de programar é grande, e neste fim de semana voltei a um tópico que há muito eu queria explorar: a versão Web do Merlin.

Abaixo as taglibs, viva o GWT!

Detesto XML. E o mesmo vale para frameworks UI que usam conceitos relacionados, baseados em taglibs e coisas afim. Logo, pensar em usar JSF para implementar o Merlin é meio que ir contra os meus princípios (bom, pelo menos da forma nativa; posso falar nisso outra hora...).

Desde que vi os primeiros esboços do GWT, eu adorei. Usar código Java puro para desenvolver telas é, simplesmente, coisiboa!

Porém, o GWT tem limitações (várias, para dizer a verdade) e, delas, a ausência de reflection é um empencilho grande para o Merlin.

Felizmente, boas almas acabam criando meios para os outros poderem avançar, e nisso, projetos como o Gwt-ent, Gwittir, SmartGwt são uma mão na roda para o Merlin.

Não vou entrar (ainda) no mérito de todos eles, mas o Gwt-ent é o foco aqui.

Gwt-ent

Vou fazer uma analogia: Sabem a API Mirror do JDK, aquela que faz parte do Annotation Processing Tool (APT)? Bem, considero o GWT-Ent e outros semelhantes a mesma coisa.

Em outras palavras, pelo que entendi, o GWT-Ent e coisas afimm processam as classes Java que precisam sofrer reflexão (que precisam implementar uma interface em específico - vide abaixo), e a partir disso, geram meta-informações que são acopladas aos bytecodes finais.

Assim, esses frameworks conseguem simular acesso reflexivo no lado cliente em tempo de execução, quando o código está, na verdade, sendo executado em Javascript no browser.

Na prática, a idéia é simples, mas ao olhar o SVN dos caras realmente tiro o chapéu, visto que é um monte de código burocrático e repetivito.

As Possibilidades

Agora, com meu primeiro exemplo funcionando, desperto a fagulha de implementar a versão Web do Merlin com GWT.

É claro, que a imagem acima mostra apenas o uso da "pseudo reflexão" para acesso simples a propriedades e métodos acessores.

Para chegar a coisas complexas, como Injeção de Dependências, inserção de Agentes e Configuração Realimentada (que é a base do Merlin) o caminho é longo.

Mas eis que demos o primeiro passso.

O Futuro

E o que vem agora?

Bem, primeiro achar uma forma para injetar a interface Reflection ou a anotação @Reflectable automaticamente nas classes que precisam sofrer a reflexão, ou seja, no mínimo, todas as que foram o Modelo de Domínio do sistema.

Imagino fazer isso via uma biblioteca CGLib ou então usar o (adoro ele) Javassist, pensando já (como meu amigo J.) em alguma Task do Ant ou então um plugin para o Maven.

O mundo é grande e a caminhada é longa. Espero que me sobrem muitos finais de semana para trabalhar ainda.

At+

Remake Merlin

Ano novo, fazemos balanços de vida. E comigo não foi diferente.

Olhei para trás e percebo que não é ruim o que fiz, mas também percebo que o que fiz não era exatamente aquilo que eu queria ter feito.

E o que eu quero fazer? O Merlin, ora essas!

Remake

Hoje, vou reconfigurar o projeto Merlin na minha instalação do Jira, em http://jboss.lm2.com.br/jira, colocando o novo esquema de permissões e afinando o projeto com a metodologia SCRUM, o que significa que vou trabalhar por metas e com sprints menores os quais, principalmente, devam ser viáveis. Fora PMP!

Mas isso não resolve, e sim as atitudes. Logo, alguns conteúdos de interesse nesse momento:

• Blog do Jeff Wilson no Javanet, que comenta uma proposta de binding para o GWT.
• Projetos no Google Code sobre binding no GWT: gwt-model, gwt-beans-binding,
• Site do metawidget, que agora é .ORG e tem tabela comparativa, incluindo o Merlin.
• EMMA Coverage Report, que é um projeto do SourceForge para testes de cobertura com ênfase na qualidade da escrita de código em Java no sentido de quão coeso, testável, integrado (e outras variáveis) ele o é, e não parece ter nada a ver com o nosso parceiro Clover; na prática, tenho que ler mais sobre ele. O Metawidget usa relatórios desse cara.

Inferência de binders

Ao entrar 2009, estive olhando alguns posts daqui e do TelasDeCadastro, e também algumas mensagens no grupo do Merlin no Google.

Olhando a mensagem http://groups.google.com/group/treelayer-merlin/t/ca5cac326c7ef33c e, em específico a imagem http://groups.google.com/group/treelayer-merlin/web/merlin-renderAsWithCustomizedBind.JPG, percebi que nada melhor do que o tempo para se fazer um bom vinho.

Estou falando da inferência de binders.

O Óbvio
Quando temos algo como:
@RenderAs(JTextField.class) boolean isAtivo;

é provável que desejamos que o campo "isAtivo" não seja mostrado com o conteúdo "true" ou "false" como abaixo:



, mas sim algo mais "humano", como "Sim" ou "Não", tal como aqui:



Claro que isso já é possível colocando o parâmetro "binder=BooleanToTextBinder.class" dentro da anotação @RenderAs, tal como mostra a figura do posto acima.

Entretanto, isso é redundante, pois se traçarmos uma relação entre o valor de @RenderAs (que é um Texto) e o tipo da propriedade isAtivo (que é um Booleano), logo percebemos que já temos essa informação!

E Então...
Logo, ter que novamente colocar um "binder=BooleanToTextBinder.class" é ferir o conceito DRY.

Por este motivo, é admissível optamos por adotar essa prática no Merlin durante a escolha dos binders na renderização das telas de cadastro.

E, caso o programador não goste do resultado, basta ele usar a premissa da Configuração por Exceção para escolher o binder que mais lhe agrada que, lembrando, vai entrar para o sistema de histórico da ferramenta e Adeus Tia Chica, como diria meu pai.