Hoje o trabalho estava fácil, e então decidi dar uma olhada na implementação do Merlin, para deixar redonda uma versão - básica, diga-se de passagem - para ser mostrada na banca do mestrado, lá por Março do ano que vem.
Pois bem, fiquei feliz, porque muitas coisas que eu estava imaginando, na verdade eu já tinha até implementado. Estou falando do RenderAs.
RenderAs
Essencialmente, como todo Gerador Baseado em Modelos, o Merlin utliza regras heurísticas para mapear um atributo de um objeto em um controle em um formulário, como um campo String mapeado para um TextBox. Muitas heurísticas existem, e é bem verdade que um grande escopo de coisas podem ser feitas automaticamente. Com mais algumas heurísticas (e essas sim, que somente o Merlin utiliza) coisas bem interessantes podem ser feitas (...)
Porém, nem sempre as heurísticas dão conta do recado. Nesses momentos, o programador precisa colocar a mão na massa e dizer, explicitamente, o que ele deseja que seja mostrado na tela. No Merlin, para fazer isso, lançamos mão da anotação @RenderAs, como no exemplo:
class Usuario {
String nome;
@RenderAs(JTextArea.class)
String descricao;
}
Ao ser renderizado um formulário para o objeto Usuario, este conterá um TextBox referente ao campo nome, e um TextArea referente ao campo descricao. Caso a anotação @RenderAs não tivesse sido utilizada, ambos campos seriam renderizados como caixas de texto simples (uma fixa, e outra variável - devido algumas heurísticas).
Neutralidade
O programador experiente logo perceberá que parece estarmos atrelando nosso objeto ao framework Swing, devido a classe JTextArea. Na verdade, isso não ocorre.
O Merlin trabalha tanto em nível físico, quanto em nível abstrato para seus mapeamentos. Em outras palavras, é possível utilizar algo como:
class Usuario {
String nome;
@RenderAs(TEXT_AREA)
String descricao;
}
Nesse exemplo, puxando mais letrinhas do mundo das ferramentas model-based, estamos trabalhando com Abstract Interface Objects (AIOs) ao invés de Concrete Interface Objects (CIOs). Hum, interessante...
Mas, novamente, um leitor atento perguntará? Bom, mas e se já tivermos uma aplicação construída para um framework como Swing ou SWT, e quisermos migrá-la para uma plataforma web, como o JSF, como faríamos ?
A resposta é: não é preciso fazer nada.
Diferente de outras ferramentas, o Merlin suporta o mapeamento bidirecional entre AIOs e CIOs, de forma que, mesmo um objeto anotado com um JTextArea poderá ser renderizado corretamente em uma aplicação para Internet.
Obviamente, essa abordagem tem seus custos. E quais são? Tão simplesmente a dependência de compilação das classes do pacote gráfico original (no caso, o Swing). Em outras palavras, um problema de projeto, e não do framework.
O futuro
Mais coisas incorrem dessas customizações, como binding e outras funcionalidades. Isso ainda não está implementado e também nem pensei no assunto, visto que, como disse no início do post, minha preocupação para o momento é deixar o que existe mais ou menos redondo, para não dar "tela azul" na frente dos homi.
Amanhã quero comentar o @Dependence.
Pois bem, fiquei feliz, porque muitas coisas que eu estava imaginando, na verdade eu já tinha até implementado. Estou falando do RenderAs.
RenderAs
Essencialmente, como todo Gerador Baseado em Modelos, o Merlin utliza regras heurísticas para mapear um atributo de um objeto em um controle em um formulário, como um campo String mapeado para um TextBox. Muitas heurísticas existem, e é bem verdade que um grande escopo de coisas podem ser feitas automaticamente. Com mais algumas heurísticas (e essas sim, que somente o Merlin utiliza) coisas bem interessantes podem ser feitas (...)
Porém, nem sempre as heurísticas dão conta do recado. Nesses momentos, o programador precisa colocar a mão na massa e dizer, explicitamente, o que ele deseja que seja mostrado na tela. No Merlin, para fazer isso, lançamos mão da anotação @RenderAs, como no exemplo:
class Usuario {
String nome;
@RenderAs(JTextArea.class)
String descricao;
}
Ao ser renderizado um formulário para o objeto Usuario, este conterá um TextBox referente ao campo nome, e um TextArea referente ao campo descricao. Caso a anotação @RenderAs não tivesse sido utilizada, ambos campos seriam renderizados como caixas de texto simples (uma fixa, e outra variável - devido algumas heurísticas).
Neutralidade
O programador experiente logo perceberá que parece estarmos atrelando nosso objeto ao framework Swing, devido a classe JTextArea. Na verdade, isso não ocorre.
O Merlin trabalha tanto em nível físico, quanto em nível abstrato para seus mapeamentos. Em outras palavras, é possível utilizar algo como:
class Usuario {
String nome;
@RenderAs(TEXT_AREA)
String descricao;
}
Nesse exemplo, puxando mais letrinhas do mundo das ferramentas model-based, estamos trabalhando com Abstract Interface Objects (AIOs) ao invés de Concrete Interface Objects (CIOs). Hum, interessante...
Mas, novamente, um leitor atento perguntará? Bom, mas e se já tivermos uma aplicação construída para um framework como Swing ou SWT, e quisermos migrá-la para uma plataforma web, como o JSF, como faríamos ?
A resposta é: não é preciso fazer nada.
Diferente de outras ferramentas, o Merlin suporta o mapeamento bidirecional entre AIOs e CIOs, de forma que, mesmo um objeto anotado com um JTextArea poderá ser renderizado corretamente em uma aplicação para Internet.
Obviamente, essa abordagem tem seus custos. E quais são? Tão simplesmente a dependência de compilação das classes do pacote gráfico original (no caso, o Swing). Em outras palavras, um problema de projeto, e não do framework.
O futuro
Mais coisas incorrem dessas customizações, como binding e outras funcionalidades. Isso ainda não está implementado e também nem pensei no assunto, visto que, como disse no início do post, minha preocupação para o momento é deixar o que existe mais ou menos redondo, para não dar "tela azul" na frente dos homi.
Amanhã quero comentar o @Dependence.
Nenhum comentário:
Postar um comentário