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.
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.
