2010-05-05 4 views
0

J'ai fait quelques applications simples avec une disposition statique, mais maintenant j'ai rencontré un problème en essayant de créer une application contenant plusieurs vues qui sont changées en appuyant sur bouton de navigation.Architecture Java Swing pour basculer entre les vues basées sur JPane

Vous pouvez comparer l'idée à un site Web de sorte que chaque vue possède des boutons permettant d'accéder à certaines autres vues, mais cela fonctionnerait dans une seule JFrame. J'ai trouvé que peut-être CardLayout (Cardlayout example) pourrait être une solution appropriée pour ce type de structure, mais je suis incapable de trouver un moyen de changer les vues à partir des boutons qui sont à l'intérieur des JPanes que je '' Bien sûr, un moyen serait d'instancier tout dans la classe parente comme dans l'exemple du petit tutoriel java, mais ce n'est pas tout à fait propre ni modulaire pour plusieurs vues, n'est-ce pas?

Comment cela peut-il être implémenté pour que je puisse accéder à la méthode de changement de vue?

+0

Peut-être quelque chose comme JTabbedPane? – medopal

+0

Qu'essayez-vous de faire, une sorte de sorcier? Si oui, il y a quelques bibliothèques open source qui pourraient vous aider (mais je ne les ai pas vérifiées depuis longtemps). Sinon, si vous avez besoin de plus de possibilités (comme plusieurs vues en même temps), vous cherchez peut-être une bibliothèque d'ancrage. S'il vous plaît clarifier davantage votre problème. – jfpoilpret

+0

Une vue à la fois suffit pour ce projet. L'objectif est de créer une application en plein écran simple contenant des composants de base tels que des listes et des boutons à utiliser avec une interface à écran tactile. Le Wizard n'est pas une description précise car il faut pouvoir se déplacer entre ces vues librement, pas dans l'ordre. – imhotep

Répondre

2

Oui, CardLayout est particulièrement approprié lorsque vous souhaitez basculer entre plusieurs vues. Évidemment, comme @medoal dit, JTabbedPane pourrait également être utilisé. Quoi qu'il en soit, vous voulez utiliser un CardLayout avec des boutons à l'intérieur des panneaux vous permettant envisager de changer le panneau visible, ce que vous feriez pourrait être:

  1. Créez vos panneaux et leur permettre d'avoir un objet qui implémente une interface donnée enregistrée. Cette interface contiendrait une méthode couvrant la méthode CardLayout#show(Container, String). Eh bien, à titre d'exemple, compte tenu de vos panneaux ont tous leurs noms fixés, et chacun de ces noms sont différents, vous pouvez écrire quelque chose comme

    interface publique PanelToggler { public void toggleTo (String name); }

  2. Dans la classe contenant la CardLayout, vous mettre en œuvre le PanelToggler avec quelque chose comme

    public void toggleTo (String name) { ((CardLayout) getLayout()). Show (ce nom) ; }

De cette façon, dans chaque panneau, aurait simplement vu chaque élément de basculement bouton de CardLayout appeler toogleTo avec l'argument correct.

+0

Merci, cela a parfaitement fonctionné pour moi. Est-ce une sorte de modèle standard pour implémenter des composants qui contrôlent des éléments dans l'élément parent? Il me semble que tous les exemples et les tutoriels sont si petits qu'ils ont tous les composants et les écouteurs instanciés dans la même classe, donc vous n'avez pas vraiment besoin de penser à propager les actions à travers les éléments parents. Ou cela peut-il être résolu avec un type d'architecture totalement différent? – imhotep

+0

En fait, le problème avec ces échantillons est qu'ils ne transmettent pas la complexité que l'application réelle a souvent. Dans la vie réelle, un modèle comme celui que j'expose ici (construire une «mini» interface dans le seul but de permettre aux enfants de prendre le contrôle de leurs parents) est souvent utile pour permettre une isolation minimale entre toutes les composantes de l'interface. En utilisant ce type de pattern, vous pouvez ironiquement appeler un "architecte", mais votre code supportera toujours le refactoring facile (refactorings qui sont de loin plus communs dans le développement de l'interface utilisateur, car le code UI n'est qu'une conséquence des choix de marketting). – Riduidel

Questions connexes