SWINGMVC Framework - Sendo desenvolvido

Pessoal, já estou em fase de testes de um framework que estou desenvolvendo, seu foco único (por enquanto), é definir desacoplamento total no desenvolvimento em camadas utilizando Swing na camada de visão. Ou seja: Ter as classes de modelo, as de controle e as de visão, sem ter dependencias (inners, etc.)

Gostaria de um feedback de vocês, no que poderia incrementar ou agregar a idéia. O funcionamento dele, para alguns, vai lembrar o Genesis (na estratégia de binding), mas quem conhece bem, vai ver as diferenças.

REGRAS:

Todas as classes controladoras deverão herdar da superclasse: swingmvc.actions.SwingMVCAction (esta, por sua vez, contém um método invocador “execute”)

Dentro das controladoras, não precisa ter nenhum tipo de configuração (xmls, annotations, nada…), você apenas deve estar ciente que: Os métodos lá contidos, podem ou não ser “bindados” com os componentes da view. Tudo irá depender de como você irá configurar a sua view.

Ex:

Controller extends SwingMVCAction { private JPanel painelPrincipal; public void setPainel(JPanel painel) { this.painelPrincipal = painel; } public void gravar() { tal.gravar... } }

A VIEW:

Precisei fazer este framework para trabalhar em conjunto com o SwingBean, mas, fiz ele pra tentando ser o máximo possível independente de frameworks, Ides, etc. Por isso as anotações estão definidas para serem SOMENTE em cima dos métodos:

[code]MinhaView {
public MinhaView() {
swingmvc.bind.Binder binder = new Binder();
binder.bind(this, new Controlador());
// Isso fará com que haja o binder do form com o controller

private JButton btnGravar;

@IsAction(method=“gravar”, type=TypeActions.CLICKED)
public void getBtnGravar() {
return btnGravar;
}

//outra diferença abaixo:

private JPanel painelPrincipal;

@IsCapsule(method=“setPainelPrincipal”)
public void getPainelPrincipal() {
return painelPrincipal;
}
/*
Este cara, faz com que na hora do bind, ele execute o método (method) que deve estar presente no controller, encapsulando o retorno da invocação do método anotado com @IsCapsule, logo, como pode ver no Controller lá em cima, fazendo o controlador conhecer quem você quiser de componentes presentes na View… para poder manipula-los dentro dos outros métodos…

*/
}
}[/code]

O Bind entende a interface TypeActions, que detem todas as principais ações usadas no dia-a-dia, como CLICKED, DOUBLECLICKED, HASFOCUS, KEYPRESS, etc. E adiciona o listener, conforme a tal.

DAS DIFERENÇAS COM O GENESIS:

O intuido deste framework é principalmente separar as Actions (todos os handlers em sí) da View.

Desculpem os erros de portugues… bom, estou preparado para as pedradas…
Em breve estarei disponibilizando no SF. Valeu…

Olá

Use o mínimo de herança possível. Lembre-se da droga do Struts para não fazer igual.

[]s
Luca

Muitoo legal!! parabens

Oi Luca. O uso obrigatorio é somente de uma herança, e no ponto principal do funcionamento do framework (controller), onde os métodos refletidos são executados e setados.

[quote=peerless]Pessoal, já estou em fase de testes de um framework que estou desenvolvendo, seu foco único (por enquanto), é definir desacoplamento total no desenvolvimento em camadas utilizando Swing na camada de visão. Ou seja: Ter as classes de modelo, as de controle e as de visão, sem ter dependencias (inners, etc.)

Gostaria de um feedback de vocês, no que poderia incrementar ou agregar a idéia. O funcionamento dele, para alguns, vai lembrar o Genesis (na estratégia de binding), mas quem conhece bem, vai ver as diferenças.

REGRAS:

Todas as classes controladoras deverão herdar da superclasse: swingmvc.actions.SwingMVCAction (esta, por sua vez, contém um método invocador “execute”)

Dentro das controladoras, não precisa ter nenhum tipo de configuração (xmls, annotations, nada…), você apenas deve estar ciente que: Os métodos lá contidos, podem ou não ser “bindados” com os componentes da view. Tudo irá depender de como você irá configurar a sua view.

Ex:

Controller extends SwingMVCAction { private JPanel painelPrincipal; public void setPainel(JPanel painel) { this.painelPrincipal = painel; } public void gravar() { tal.gravar... } }

A VIEW:

Precisei fazer este framework para trabalhar em conjunto com o SwingBean, mas, fiz ele pra tentando ser o máximo possível independente de frameworks, Ides, etc. Por isso as anotações estão definidas para serem SOMENTE em cima dos métodos:

[code]MinhaView {
public MinhaView() {
swingmvc.bind.Binder binder = new Binder();
binder.bind(this, new Controlador());
// Isso fará com que haja o binder do form com o controller

private JButton btnGravar;

@IsAction(method=“gravar”, type=TypeActions.CLICKED)
public void getBtnGravar() {
return btnGravar;
}

//outra diferença abaixo:

private JPanel painelPrincipal;

@IsCapsule(method=“setPainelPrincipal”)
public void getPainelPrincipal() {
return painelPrincipal;
}
/*
Este cara, faz com que na hora do bind, ele execute o método (method) que deve estar presente no controller, encapsulando o retorno da invocação do método anotado com @IsCapsule, logo, como pode ver no Controller lá em cima, fazendo o controlador conhecer quem você quiser de componentes presentes na View… para poder manipula-los dentro dos outros métodos…

*/
}
}[/code]

O Bind entende a interface TypeActions, que detem todas as principais ações usadas no dia-a-dia, como CLICKED, DOUBLECLICKED, HASFOCUS, KEYPRESS, etc. E adiciona o listener, conforme a tal.

DAS DIFERENÇAS COM O GENESIS:

O intuido deste framework é principalmente separar as Actions (todos os handlers em sí) da View.

Desculpem os erros de portugues… bom, estou preparado para as pedradas…
Em breve estarei disponibilizando no SF. Valeu…[/quote]

Cara, vou fazer umas críticas, mas não leve isso pro lado pessoal, é só pra ajudar a melhorar o seu framework:

1- Como o Luca falou, evite a herança pra evitar a droga do Struts 1.x. Não sei a responsabilidade da classe SwingMVCAction, mas se puder mudar para uma annotation ou uma interface, melhor.

2- Na view, o seu binder chama o código:

swingmvc.bind.Binder binder = new Binder();
binder.bind(this, new Controlador()); 

porém, é do SEU framework a responsabilidade de criar instâncias, não do usuário. Isso pode ser bobeira, mas dá mais flexibilidade ao seu framework. Troque por algo como:

swingmvc.bind.Binder binder = new Binder();
binder.bind(this, Controlador.class);

ou então uma anotação em cima da classe de visão:

@View(notifyAction=Controlador.class)
class MinhaView {
...
}

3 - Não adianta muito o controller ter uma instância da camada de visão, senão você não consegue cumprir a promessa de desacoplamento total. Portanto, a anotação @IsCapsule(method=“setPainelPrincipal”) em cima de um getPainelPrincipal é ruim. Porém, ainda não consigo imaginar um outro jeito.

4 - Está faltando um bind da view pro model, pra que, quando o model é alterado, a view reflita isso.

Ok?

Oi Leonardo3001, muito legal suas idéias. Vou ver uma forma bacana de adequar algo ai citado.

Quando ao IsCapsule, realmente, fiz ele, exatamente, para dar a libertade do desenvolvedor apenas mostrar para o controller os componentes que ele desejar. (Lembra que disse, que fiz para trabalho com o SwingBean? Quem trabalha com o SwingBean sabe, que a única coisa acoplada, é o controller… pois o model já vem, digamos, “bindado” a um Panel)

Quanto a fazer bind do modelo, estou pensando em uma maneira mais flexível, mais para frente, pois a visão atual, eu deveria fazer no máximo, uma cópia do que hoje faz o Genesis, JGoodies, etc.

Valeu! :slight_smile:

EDITADO,

Conforme sugestão do Leonardo e do Luca, acadata por mim, agora nenhum controlador mais precisa herdar de ninguém.

E agora tbm não precisa passar instancias do controlador na hora do bind, apenas:

Binder bind = new Binder(); bind.bind(this, Controller.class);

Alguns comentários:

  1. to bind : vincular . bind : vinculo. binder :vinculador.

  2. O que vc está fazendo não é MVC é MVP. A arquitetura MVC implica em que cada uma das tres parte tem conexão com as outras
    Não é o caso. A View só se liga ao controlador e o controlador ao modelo , não é mesmo ? Dê uma olhada
    neste padrão é muito melhor que MVC para coisa de alto nivel e elimina o problema de vincular o modelo ao view. ( bem, quase elimina)

  3. Básicamente, se vc levar todas as ideias a bom porto e for fundo , vc vai chegar ao mesmo lugar que outros frameworks chegaram
    Para ser util o controlador não pode ter dependencia da view ( o seu setPanel() não é uma boa) Daqui vc conclui que a unica forma
    é encapsular os eventos e modelos de dados dos objetos da view, e não a view em si mesma. Isso é algo como o JGoodies Binding.
    Pense assim : o controlador web não sabe o que é um browser. Também o controlador swing não sabe o que é uma janela, um botão, etc.
    Este isolamento é muito bem visto pelo pessoal de testes unitários já que todos os outros objetos podem ser mocks e vc pode testar o controlador
    sem sequer necessitar de objetos swing sendo instanciados.

  4. O seu vinculo de ações parece limitado ( não vi tudo ,apenas li seu exemplo) Como é que eu reajo, por exemplo, a um duplo click
    numa linha de uma tabela ? e de uma celula expecifica ? Por outro lado, ações de botões não deveria precisar de um tipo já que só há uma forma de ativar o botão.

Em resumo, swing é muito poderoso. Se vc oferece uma ferramenta que retira 80% da funcionalidades para tornar 10% mais simples não é um grande trade-off.

Mas mesmo assim é uma boa inciativa, continua!

[quote=sergiotaborda]Alguns comentários:

  1. to bind : vincular . bind : vinculo. binder :vinculador.

  2. O que vc está fazendo não é MVC é MVP. A arquitetura MVC implica em que cada uma das tres parte tem conexão com as outras
    Não é o caso. A View só se liga ao controlador e o controlador ao modelo , não é mesmo ? Dê uma olhada
    neste padrão é muito melhor que MVC para coisa de alto nivel e elimina o problema de vincular o modelo ao view. ( bem, quase elimina)

//A idéia ao decorrer é implementar o MVC totalmente. Caso veja, que não haja necessidade disso, altero o nome do projeto

  1. Básicamente, se vc levar todas as ideias a bom porto e for fundo , vc vai chegar ao mesmo lugar que outros frameworks chegaram
    Para ser util o controlador não pode ter dependencia da view ( o seu setPanel() não é uma boa) Daqui vc conclui que a unica forma
    é encapsular os eventos e modelos de dados dos objetos da view, e não a view em si mesma. Isso é algo como o JGoodies Binding.
    Pense assim : o controlador web não sabe o que é um browser. Também o controlador swing não sabe o que é uma janela, um botão, etc.
    Este isolamento é muito bem visto pelo pessoal de testes unitários já que todos os outros objetos podem ser mocks e vc pode testar o controlador
    sem sequer necessitar de objetos swing sendo instanciados.

  2. O seu vinculo de ações parece limitado ( não vi tudo ,apenas li seu exemplo) Como é que eu reajo, por exemplo, a um duplo click //Não é limitado, todas(1) as ações na interface TypeActions já implementadas na estratégia do vínculo
    numa linha de uma tabela ? e de uma celula expecifica ? Por outro lado, ações de botões não deveria precisar de um tipo já que só há uma forma de ativar o botão.

//Neste caso, como contrato do framework, exige-se que a view possua um método que retorne a tabela em questão, anotado por @IsCapsule, e adicionando a ação com @IsAction, referenciando a TypeActions com DOUBLECLICKED

Em resumo, swing é muito poderoso. Se vc oferece uma ferramenta que retira 80% da funcionalidades para tornar 10% mais simples não é um grande trade-off.

//Como disse lá em cima, para mim resolveu o problema da separação da view com o handler. Mas, apartir do momento que abri este tópico, estou aberto para idéias, para tornar isso flexível para todos.

Mas mesmo assim é uma boa inciativa, continua!
//Valeu, muito obrigado pelo comentário, me deu algumas idéias!
[/quote]

Está insinuando também, que é melhor investir conhecimento em RoR do que em Java? Sem desfocar o assunto do tópico, mas ví uma palestra na latinoware deste ano sobre RoR, e o que me parece, o Rails “GERA” todas as camadas e já define a arquitetura. Isso não torna um projeto dependente da arquitetura em questão?

Achei bem interessante. Parabéns pela iniciativa. Não entendi o que isso possa ter haver com o RoR. Quando que teremos um site?

[quote=saoj]
Achei bem interessante. Parabéns pela iniciativa. Não entendi o que isso possa ter haver com o RoR. Quando que teremos um site?[/quote]

Oi saoj, muito obrigado por sua opinião. Realmente, o fake do pcalçado foi infeliz no seu comentário.

Teremos um site, assim que o framework se mostrar consistente em pelo menos três casos de uso do ERP aqui da empresa.

Abração! :thumbup:

Pelo que eu sei isso é algo MUITO sério, tb conhecido como crime de falsidade ideológica. Seria bom os moderadores removerem esse carinha, anotarem o IP e as datas, e avisarem o Phillip, se não for realmente ele com uma nova conta.

Olá peerless,

Idéia legal, porém uma dúvida ! O que você está inventando, não é o Genesis ?

Estou perguntando, porque é muito mais útil desenvolver/melhorar algo que já exista
do que criar “concorrência” não ?

Caso não seja a mesma coisa, por favor ignore minha mensagem. :slight_smile:

flw e sucesso!
Roger Leite

[quote=Roger–]Olá peerless,

Idéia legal, porém uma dúvida ! O que você está inventando, não é o Genesis ?

Estou perguntando, porque é muito mais útil desenvolver/melhorar algo que já exista
do que criar “concorrência” não ?

Caso não seja a mesma coisa, por favor ignore minha mensagem. :slight_smile:

flw e sucesso!
Roger Leite[/quote]

Oi amigo,
não, não é o Genesis. O Genesis trabalha como uma mistura da Visão+Modelo, minha idéia inicial é:

Visão+Controller (diga-se de passagem, um controller mesmo, que só trate os eventos, e acesse o modelo)

Como pôde ver, tbm lhe permite escolher qual evento executara determinado método, como podemos observar a interface TypeActions

TypeActions.CLICKED
TypeActions.DOUBLECLICKED
TypeActions.HASFOCUS
TypeActions.KEYPRESSED
TypeActions.etc

Cairá como uma luva para usuários do SwingBean, para separar a view do controle.

E também poderá ser usado em conjunto com o Gênesis, alem das diversas outras funcionalidades que o Genesis oferece.

Abração

Olá peerless!!!

Acredito que as novas funcionalidades de binding do SwingBean podem ajudar bastante a tornar as coisas independentes!!!

Porque a gente não “junta” os projetos e você desenvolve o seu framework como parte do SwingBean? Tipo “SwingBean MVC”, ou algo do tipo…

[]s

[quote=Guerr@]Olá peerless!!!

Acredito que as novas funcionalidades de binding do SwingBean podem ajudar bastante a tornar as coisas independentes!!!

Porque a gente não “junta” os projetos e você desenvolve o seu framework como parte do SwingBean? Tipo “SwingBean MVC”, ou algo do tipo…

[]s[/quote]

Olá Guerra, eu troquei de empresa no inicio deste ano, e consequentemente havia dado uma “parada” com o framework, até mesmo evolui bem mais ele, mas não atualizei este tópico. Ele e o swingbean estão em produção ainda na minha ex-empresa, e foi muito bem acatado, onde está sendo finalizado um grande ERP!

Gostei da idéia, poderiamos juntar sim o SwingMVC com o SwingBean, acho que ai sim teria uma melhor importância para o meu framework, focando ele somente em controle MVC, e não em binds. Vou dar uma trabalhada no código do SwingBean e te passar um feedback do que poderia ser feito, em breve.

at+

Como você saiu da empresa, é bom verificar com seu ex-chefe antes se você pode liberar o código ou tem de começar do zero. Esse negócio de propriedade intelectual pode dar uma dor de cabeça séria.

De qualquer forma, parabéns pela iniciativa!

Oi,

[quote=rubinelli]Como você saiu da empresa, é bom verificar com seu ex-chefe antes se você pode liberar o código ou tem de começar do zero. Esse negócio de propriedade intelectual pode dar uma dor de cabeça séria.

[/quote]

Acho que não tem problemas não. Pois na verdade fiz como projeto independente e sob licença LGPL.

Obrigado! :stuck_out_tongue:

A iniciativa é mto boa… e garanto que quando liberar o projeto eu serei um dos contribuidores… aqui na empresa onde trabalho temos sempre problemas com arquitetura MVC em aplicações Swing. Chegamos a algo que ainda está longe do ideal… to botando muita fé no projeto…
Abra um repositorio pra comunidade java ajudar no desenvolvimento…