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.
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.
[quote=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.[/quote]
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.
É 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
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.