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

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

interface Funcionario {
    public Object getNome();
    public Object getEstadoCivil();
    public Object getEstaAfastado();
}

class FuncionarioImpl implements Funcionario, Model {
    // declara os campos e os getters das propriedades
}

class FuncionarioView extends View implements Funcionario {
    public FuncionarioView( Funcionario model ) {
        this.model = ( FuncionarioImpl ) model;
    }

    public JComponent getNome() {
        return new JTextField( model.getNome() );
    }

    public JComponent getEstadoCivil() {
        // retorna uma combobox com a opção correta selecionada
    }

    public JComponent getEstaAfastado() {
        return new JCheckBox( model.getEstaAfastado() );
    }
}

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.

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 ?

Instancia as duas view oras.

Cara, você pode aprender Tapestry

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.

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.

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.

Olá,

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

]['s

Essa parte:

jprogrammer:

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.

public class PessoaViewHTML implements PessoaView {
    public Component getName() {
        return new Component( "<input type=\"text\" value\"" + model.getName() + "\"/>" );
    }
}

:XD:

É 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

Pela ideia do LIPE não precisaria fazer consulta no metadados do banco, mas sim em um tipo de “meta dados” do objetos é que realmente importa.
Sim hoje todos nós utilizamos esse recurso (find - replace).
Mas o problema não é só a mudança, mas a integridade do sistema e a produtividade.
Já vi muito programador, (inclusive eu) que deixa campo númerico aceitar letra, tamanho de campo diferente, tela sem padrão.
São coisas miudas de tiram a qualidade do sistema.
Mas é lógico que não procuro uma solução mirabolante, mas gostaria de ver a ideia do pessoal.