Navegação entre JFrame's/JPanel's

http://www.guj.com.br/java/55710-jdialog-devolvendo-valor-pra-jinternalframe#292687

Cuidado: Se você usa DefaultTableModel, não tem uma aplicação em MVC.

você quer fechar um e abrir outro? Não entendi…

ViniGodoy:

http://www.guj.com.br/java/55710-jdialog-devolvendo-valor-pra-jinternalframe#292687

Cuidado: Se você usa DefaultTableModel, não tem uma aplicação em MVC.

Não ??? :shock:

Eu não entendo nada de MVC, o professor simplesmente quer que a gente faça e até agora não consegui desenvolver nada, praticamente nem sai da parte de fazer as telas… :S

Se não utilizar DefaultTableModel, posso utilizar o que para fazer as tabelas ?

Outra dúvida:

Esse é o diagrama de classes do caso de uso Manter Aeronave:

E esse é o Diagrama de Sequência para incluir aeronave:

De acordo com esses diagramas, vou ter que implementar classes com os mesmos métodos e atributos ? Elas vão ser idênticas em questão de assinatura dos métodos e dos atributos) ?

Não não… Quero que fique no mesmo JFrame, como se só mudasse o JPanel…

Sabe quando você ta instalando um programa, e clica em next, next, next ? É a mesma coisa…

Nos exemplos que vi do CardLayout, tinha que ter mais de um painel, em que um deles, ficava ‘fixo’ no JFrame contendo os botões e de acordo com o botão clicado, mudava o JPanel com os JLabel…

Tentei transformar as telas (JFrame’s) em JPanel e usar o CardLayou, mas não deu certo…

ViniGodoy:

http://www.guj.com.br/java/55710-jdialog-devolvendo-valor-pra-jinternalframe#292687

Cuidado: Se você usa DefaultTableModel, não tem uma aplicação em MVC.

Outra coisa ViniGodoy: se dissesse que li o link que mandou e tentei fazer algo com as informações, não estaria falando a verdade, mas está falando de JDialog ?

Se for, na verdade, a tela de consulta não seria um JDialog, ela apareceria no mesmo JFrame que menu inicial, igual a instalação de um software quando se clica em next.

Não entendi. Por que você quer usar o Cardlayout, se seu sistema não tem nem sequer cara de um instalador?

Para manter o MVC com Swing, você deve implementar seu próprio TableModel. O TableModel, apesar do nome, faz o papel do Controller no caso da JTable.
Veja o link da minha assinatura, que tem vários exemplos ao lado do texto em vermelho.

ViniGodoy:

Não entendi. Por que você quer usar o Cardlayout, se seu sistema não tem nem sequer cara de um instalador?

Para manter o MVC com Swing, você deve implementar seu próprio TableModel. O TableModel, apesar do nome, faz o papel do Controller no caso da JTable.
Veja o link da minha assinatura, que tem vários exemplos ao lado do texto em vermelho.

Citei o instalador como um exemplo de como quero que minhas funcionem. Veja no video como está, comparando com um instalador:

[youtube]http://www.youtube.com/watch?v=PG4vqSQK2_8&feature=youtu.be[/youtube]
http://www.youtube.com/watch?v=PG4vqSQK2_8&feature=youtu.be

ViniGodoy:

Não entendi. Por que você quer usar o Cardlayout, se seu sistema não tem nem sequer cara de um instalador?

Para manter o MVC com Swing, você deve implementar seu próprio TableModel. O TableModel, apesar do nome, faz o papel do Controller no caso da JTable.
Veja o link da minha assinatura, que tem vários exemplos ao lado do texto em vermelho.

Aproveitando aqui(não eu não vou me aproveitar do teu tópico e desviar o caminho, é só uma duvida que tem a ver e pode ate te ajudar):

Estava fazendo um aplicativozinho bem básico um dia desses e veio a dúvida:

Estava desenvolvendo em MVC e como era uma coisa bem simples usei só 3 classes, exatamente uma pra cada “camada”(sem entrar no mérito dessa palavra que ja gerou mt discussao por aqui :D).

A duvida é, eu posso mandar meu modelo extender diretamente o AbstractTableModel? No caso facilitava umas coisas pra mim(várias :D), por outro lado eu estava “engessando” o MVC já que estava extendendo uma classe do swing. Assim, se minha apresentacao mudasse, muito provavelmente teria que mexer no modelo, acabando com os beneficios do MVC.

Entao eu mandar meu modelo extender diretamente AbstractTableModel voces acham que é um “anti-padrao”? Sempre devo criar o modelo das tabelas separado?

wesleyosilva tambem não sei porque usar esse CardLayout. Sinceramente eu não sei pra que ele serve, mas vejo uma forma de resolver teu problema(nao sei se é a melhor e posso ate estar “reinventando a roda” por existir algum componente pronto para tal):

Voce iria ter um Frame principal e dentro as instancias dos teus paineis(ou voce poderia sempre cria-las em tempo de execucao). De acordo com o botao que o cara clicou vc removeria o painel atual, adicionaria o novo e daria um pack no Frame. Só isso.

carlos.e.a:

wesleyosilva tambem não sei porque usar esse CardLayout. Sinceramente eu não sei pra que ele serve, mas vejo uma forma de resolver teu problema(nao sei se é a melhor e posso ate estar “reinventando a roda” por existir algum componente pronto para tal):

Voce iria ter um Frame principal e dentro as instancias dos teus paineis(ou voce poderia sempre cria-las em tempo de execucao). De acordo com o botao que o cara clicou vc removeria o painel atual, adicionaria o novo e daria um pack no Frame. Só isso.

Hum… Acredito que seja isso que o CardLayout faça, ela troca os paineis, porém troquei uma tela JFrame, por JPanel, e não deu certo. Vou tentar de novo e coloco aqui o código e o resultado.

E na verdade não precisa ser o CardLayout, só queria que as telas fossem exibidas no mesmo JFrame ao invés de ficar abrindo outros, citei o CardLayout pois foi o único que vi que e mais falado que faça a navegação.

wesleyosilva:

carlos.e.a:

wesleyosilva tambem não sei porque usar esse CardLayout. Sinceramente eu não sei pra que ele serve, mas vejo uma forma de resolver teu problema(nao sei se é a melhor e posso ate estar “reinventando a roda” por existir algum componente pronto para tal):

Voce iria ter um Frame principal e dentro as instancias dos teus paineis(ou voce poderia sempre cria-las em tempo de execucao). De acordo com o botao que o cara clicou vc removeria o painel atual, adicionaria o novo e daria um pack no Frame. Só isso.

Hum… Acredito que seja isso que o CardLayout faça, ela troca os paineis, porém troquei uma tela JFrame, por JPanel, e não deu certo. Vou tentar de novo e coloco aqui o código e o resultado.

E na verdade não precisa ser o CardLayout, só queria que as telas fossem exibidas no mesmo JFrame ao invés de ficar abrindo outros, citei o CardLayout pois foi o único que vi que e mais falado que faça a navegação.

Você tem que dar o remove no outro painel, ok? Talvez fosse bom voce colocar o codigo pra ver se tem algum errinho, pq eu ja fiz isso e deu certo tranquilo.

carlos.e.a:

A duvida é, eu posso mandar meu modelo extender diretamente o AbstractTableModel? No caso facilitava umas coisas pra mim(várias :D), por outro lado eu estava “engessando” o MVC já que estava extendendo uma classe do swing. Assim, se minha apresentacao mudasse, muito provavelmente teria que mexer no modelo, acabando com os beneficios do MVC.

Entao eu mandar meu modelo extender diretamente AbstractTableModel voces acham que é um “anti-padrao”? Sempre devo criar o modelo das tabelas separado?

De jeito nenhum. Lembre-se que herança significa “é um”. Se você tiver um modelo, digamos, a classe Cliente, e estender de AbstractTableModel, você estará dizendo que um cliente “é um AbstractTableModel”.

Além disso, o TableModel é uma classe de controle, não de model.

Eu sei que seu sistema não é um instalador, e que instalador era um exemplo.

Eu perguntei porque seu sistema tem cara de sistema de janelas, no entanto, tem uma navegabilidade de instalador, o que você não encontra comumente em aplicações por aí.
Geralmente, manter uma janela só que troca de conteúdo é comum em instaladores e Wizards. Para aplicações, as janelas além do menu costumam a ser de dois tipos:
a) Janelas de dialogo: Do tipo que o usuário abre, dá alguma informação e fecha - muitas vezes retornando a informação para a janela que abriu o dialogo;
b) Janelas comuns: Onde o usuário pode ter várias janelas abertas ao mesmo tempo, e onde elas normalmente não trocar dados entre si.

Outra opção comum hoje em dia, quando o aplicativo gerencia operações similares é a opção de abas.

Antigamente, havia também a possibilidade de janelas que abrem de outras janelas (chamadas no Java de InternalFrames). Não tenho visto mais aplicações com esse idioma há vários anos.

É, ainda tem esse outro agravante de OO. Acho que vou desfazer

Sério? :shock:

Agora fiquei confuso, sempre pensei que fosse de model. Não é ela que fornece o modelo para a tabela? Não é lá que colocamos a lista de negocio da tabela?
Outro indicio de que a TableModel é o modelo é que é o AbstractTableModel que implementa o observable(de um modo diferente, com aqueles firetablexxx mas nao deixa de ser uma variacao do padrao Observer) e avisa sobre mudanças NELE, no caso o modelo. Em geral quem tem essa funcao no MVC é o modelo : \

Tem como explicar melhor essa sua afirmacao? Nao entendi mesmo.

O mecanismo de eventos e as chamadas de métodos são a forma das diferentes camadas se comunicarem em desktop.

Em web, o controller exige uma mecânica mais complicada, uma vez que existe um protocolo de comunicação entre a view e o model.

Veja as atribuições do TableModel:

a) Receber os dados que foram digitados na tabela e repassar a classes de negócio, para atualiza-los;

b) Fazer validações dos dados de entrada;

c) Informar a view que os dados foram alterados.

Quem no modelo MVC tem essas responsabilidades?

ViniGodoy:

O mecanismo de eventos e as chamadas de métodos são a forma das diferentes camadas se comunicarem em desktop.

Em web, o controller exige uma mecânica mais complicada, uma vez que existe um protocolo de comunicação entre a view e o model.

Veja as atribuições do TableModel:

a) Receber os dados que foram digitados na tabela e repassar a classes de negócio, para atualiza-los;

b) Fazer validações dos dados de entrada;

c) Informar a view que os dados foram alterados.

Quem no modelo MVC tem essas responsabilidades?

O modelo

Segundo o modelo de MVC que estudei, funciona como se fosse um “giro”. Quem avisa para a apresentacao que mudou é o proprio modelo, usando para tanto o padrao Observer. Funciona da seguinte forma: Modelo implementa Observer, View se registra como observador do modelo, View usa Strategy com o Controle. Basicamente seria isso.

No caso da validação, geralmente faço isso pelos eventos da propria JTable, que considero que seja o controle(qualquer material sobre JTable diz que a propria tabela é o controle) e não pelo set do TableModel, que no caso teria a responsabilidade de apenas receber os dados.

Vai ser bem dificil me convencer que TableMODEL é o controle :roll:

O motivo de tanta confusão é que o Swing implementa um padrão chamado Simplified MVC. Nesse modelo, o controller praticamente some, deixando o model com responsabilidade de modelo e de controle. Isso porque, como a view é “grudada” na mesma aplicação do model, praticamente some a necessidade de um controlador complexo.

Por isso é tão difícil enquadrar o TableModel no MVC puro. Eu prefiro compara-lo ao controller, pois ele certamente não tem qualquer responsabilidade sobre regras de negócio. Ele faz validação de dados de entrada, mas delega as regras de negócio para a classe que o JTable gerencia. Assim, ele fica mais próximo do que colocaríamos num controller web.

Mas a rigor você está certo: ele não é totalmente o controller. Mas não é totalmente o model também.

ViniGodoy:

O motivo de tanta confusão é que o Swing implementa um padrão chamado Simplified MVC. Nesse modelo, o controller praticamente some, deixando o model com responsabilidade de modelo e de controle. Isso porque, como a view é “grudada” na mesma aplicação do model, praticamente some a necessidade de um controlador complexo.

Por isso é tão difícil enquadrar o TableModel no MVC puro. Eu prefiro compara-lo ao controller, pois ele certamente não tem qualquer responsabilidade sobre regras de negócio. Ele faz validação de dados de entrada, mas delega as regras de negócio para a classe que o JTable gerencia. Assim, ele fica mais próximo do que colocaríamos num controller web.

Mas a rigor você está certo: ele não é totalmente o controller. Mas não é totalmente o model também. :)

Ha, entendo. É só uma questao de visao mesmo entao da coisa. Quando vi que voce tinha dito que o TableModel era o controle pensei que ele NUNCA poderia ser o modelo, e que era loucura pensar de tal forma. Eu só questionei pq eu realmente levo bastante em consideração o que voce diz(e que eu podia estar totalmente equivocado) por sua experiencia. Inclusive o modo como eu entendia MVC era totalmente errado e foi vendo alguns posts seus que eu resolvi estuda-lo novamente. Hoje eu acho que entendo melhor, mas ao ver isso tomei um susto e achei q ia ter que estudar tudo de novo

Se quiser se aprofundar:
http://www.oracle.com/technetwork/java/architecture-142923.html

Eu sei que seu sistema não é um instalador, e que instalador era um exemplo.

Eu perguntei porque seu sistema tem cara de sistema de janelas, no entanto, tem uma navegabilidade de instalador, o que você não encontra comumente em aplicações por aí.
Geralmente, manter uma janela só que troca de conteúdo é comum em instaladores e Wizards. Para aplicações, as janelas além do menu costumam a ser de dois tipos:
a) Janelas de dialogo: Do tipo que o usuário abre, dá alguma informação e fecha - muitas vezes retornando a informação para a janela que abriu o dialogo;
b) Janelas comuns: Onde o usuário pode ter várias janelas abertas ao mesmo tempo, e onde elas normalmente não trocar dados entre si.

Outra opção comum hoje em dia, quando o aplicativo gerencia operações similares é a opção de abas.

Antigamente, havia também a possibilidade de janelas que abrem de outras janelas (chamadas no Java de InternalFrames). Não tenho visto mais aplicações com esse idioma há vários anos.

Ahh mas não teria como fazer como a minha idéia ? Você acha que do jeito que expliquei vai ser muito difícil/ruim implementar e ainda utilizar MVC + DAO (que ainda tô perdido principalmente por não ser igual ao projeto) pra mim que sou iniciante ?

Tem sim, é só implementar vários JPanels e um CardLayout. Mas é mais trabalhoso, sem dúvida.