Integração GUI X Modelo Dados/Negócio

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Vou tocar em um ponto em que frequentemente insisto.
Gostaria da opinião de vocês.

Existe um framework ou recurso em algum framework para refletir o modelo de dados /negocio na GUI ?
ex:

- Tenho o campo código de funcionário em várias telas.
Tem o tamanho 10, mas um belo dia muda para 15.

-Tenho um campo tipo de afastamento (FÉRIAS, DEMISSÃO, AFASTAMENTO MÉDICO...).
Este campo é usado em várias telas e desejo colocar mais uma opção.

Vocês tem alguma dica. Tenho algumas ideias, mas gostaria da opinião de vocês.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Com a ajuda do shoes e do cv, desenvolvi algo que cabe exatamente nisso que você precisa. Meio por cima, funciona assim no Tiger:

Maaais ou menos isso cara. Mas consegui remover os getters feios

Desta maneira, qualquer formulário que precisar qualquer coisa relacionada a um funcionário, instancia um objeto FuncionarioView. Se algum dia precisar mudar qualquer regra sobre os componentes, só precisa mudar em um lugar.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

No caso é uma interface WEB, mas da para aproveitar a ideia.

Mas se tela tivesse campos de funcionario e outra entidade qualquer.
Como eu juntaria os dois views ?

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Instancia as duas view oras.

Cara, você pode aprender Tapestry

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Já dei uma olhada no Tapestry.
É um pouco complexo, mas parece que para este caso serve.

Mas dá para perceber que o pessoal geralmente faz é alterar manualmente o código nestes casos.
É find-replace mesmo.

São coisas que também não mudam assim toda hora.
Mas gostaria de ouvir mais ideias...

Se o cliente fosse Swing valeria a pena conhecer a biblioteca Binding do JGoodies. Pode ser encontrada no java.net.

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

O genesis resolve isso por fazer binding também, de um jeito bem diferente que o JGoodies faz (e eu sou suspeito se disser que gosto mais do jeito que o genesis faz, anyway, por ser o fundador do projeto). Dê uma olhada, provavelmente vai te ajudar.

Eu tou apanhando em como fazer binding em GUIs, aplicações web são bem mais simples, e a atual solução é próxima a forma de binding do JGoodies; que se resume a tanto o model e o view serem JavaBeans com bounded properties e um pouco de reflection para a cola.

Michael, vou dar uma olhada no genesis, mas se lembro bem da sua palestra, vou precisar adaptar um pouco, já que uso SWT.

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

louds wrote:Michael, vou dar uma olhada no genesis, mas se lembro bem da sua palestra, vou precisar adaptar um pouco, já que uso SWT.

No mínimo, a idéia em si vai servir, mas acredito que você vai precisar apenas escrever um novo binder, o que é bem mais simples do que parece (o atual tem bem menos de 1000 linhas, não lembro quantas exatamente agora).

A grande diferença entre o modelo do genesis e do JGoodies é que, além de o genesis fazer mais coisas, o genesis não acredita nessa idéia de atualizar a interface a cada vez que as propriedades mudam, já que muitas mudanças podem ser apenas temporárias ou parte de uma maior. Além disso, algumas mudanças podem ser, se consideradas parcialmente, inválidas, o que não funcionaria em conjunto com as outras funcionalidades que o genesis oferece.

This message was edited 1 time. Last update was at 25/04/2005 17:28:09

Olá,

E eu achei que o JProgrammer tava falando do tamanho fisico dos campos na tela e nao de binding.

]['s

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

fabgp2001 wrote:E eu achei que o JProgrammer tava falando do tamanho fisico dos campos na tela e nao de binding.

Essa parte:

jprogrammer wrote:Tenho um campo tipo de afastamento (FÉRIAS, DEMISSÃO, AFASTAMENTO MÉDICO...).
Este campo é usado em várias telas e desejo colocar mais uma opção.

tem a ver com binding

Realmente ele não está falando de binding.

Mas a sugestão do lipe é uma boa, olha o tapestry ou JSF. Ambos permitem desenvolvimento orientado a componentes, oque resolve o problema que o JProgrammer comentou.

Outra solução é usar includes com constantes/macros para esses vários elementos da gui.

Uma idéia seria modificar as taglibs do struts/webwork para interpretarem annotations e colocar esses valores nelas.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

This message was edited 3 times. Last update was at 26/04/2005 08:57:28

É mas ou menos isso LIPE que estou pensando.
Na verdade tem a ver com binding e com o tamanho físico dos campos.
Na verdade não seria o binding dos dados, seria mais ou menos como os dominios dos banco de dados. É uma lista de valores possíveis.

Estava pensando em alguma coisa como esta.
Isso traria uma abstracao enorme da interface.
O programador que está utilizando essa API nem precisaria se preocupar com HTML, Javascript, etc.
E ainda teria a reutilizacao dos padroes de tamanho de campo, tipo de dados, etc.

A partir dai como eu montaria o form lipe ?
Poderia até fazer binding também.
Para não comercar do zero e se fosse extendido alguma classe Action do sruts ou webwork para criar os forms. Sei lá...

A ideia dos annotations também é boa.
Mas não queria depender do 1.5

Estava pensando também em custom tag libraries.

Você acha que o modelo de dados muda tanto assim a ponto de fazer valer a pena montar os forms dinamicamente?

Não estaria adicionando uma consulta a metadados do banco para uma coisa que vai ser util algumas poucas vezes?

Será que um search & replace já não resolve seu problema?

[]'s
Marco Campêlo

Notícias, artigos e o maior fórum brasileiro sobre Java