peerless wrote: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:

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.. */ } }


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..

sergiotaborda wrote: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

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 //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!

pcalcado. wrote:Cara gostei da ideia pena q o RoR ta na area agora acho q isso nao vai vingar , desculpe a franqueza amigo

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

Realmente, o fake do pcalçado foi infeliz no seu comentário.

Roger-- wrote: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.

flw e sucesso!
Roger Leite