Discussion :

[710dom]

Bonjour,

Je me suis posé la question suivante, sur quel type d'objet pouvait-on appliquer un Layout manager via la méthode setLayout.
Après quelques recherches, j'ai trouvé que cette méthode (setLayout) est implantée dans la classe Container.
Dans les différents exemples que j'ai trouvé sur net, la méthode setLayout() est appliquée sur le ContentPane d'un JFrame via getContentPane(). Normal, puisque getContentPane() renvoie un Container.
D'autres exemples appliquent le setLayout() sur un JPanel, normal puisque JPanel hérite de Container.

Mais JFrame hérite également de Container, je me suis donc dit que l'on pouvait appliquer un setLayout() sur un JFrame.

Et ca marche:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
import java.awt.BorderLayout;
 
public class Application {
 
	public static void main(String[] args) {
		@SuppressWarnings("unused")
		Fenetre fenetre = new Fenetre("Ma fenètre");
		fenetre.setLayout(new BorderLayout());
	}
 
}

Fenetre hérite de JFrame.

Mais quelle est l’intérêt, ne doit-on pas placer (et donc ordonnancer) les composants sur le contentPane de ce JFrame ?

En clair, pourquoi JFrame hérite de Container ?
Et donc pourquoi peut-on appliquer un setLayout() directement sur un JFrame ?

Cordialement

[bouye]

EDIT - j'ai totalement réécrit ma réponse.

Une JFrame se contente de déléguer l'appel de cette méthode et le traitement qui va avec a son contentPane qui est le conteneur racine affiché dans la fenêtre.
Sommes toutes en fait il te faudrait plutôt faire frame.getContentPane().setLayout(...) mais pour des raisons pratiques c'est plus simple de l'invoquer directement sur la fenêtre.
De la même manière, tu peux directement invoquer les multiples variantes de add() et remove() directement sur la JFrame... euh depuis le JDK 5 semble-t-il d’après ce que je trouve sur le net (ca ne devait pas marcher bien avant) mais ne prend pas tout ce que j'ecris pour argent comptant car ça date quand même de plus de 15 ans .

C'est probablement car Swing a été écrit comme étant une sorte de surcouche lightweight d'AWT avec les principales classes de Swing qui héritent directement des classes d'AWT. D'une part ça permettait de mélanger les deux avec plus ou moins de succès et d'autre part sans doute que Netscape (Netscape a créé JFC en tant que lib externe pour le JDK 1.1.8 ou 9 je sais plus et l'a donné a Sun qui en a fait Swing et l'a integre a Java 2 1.2) ne voulait pas vraiment aller extraire des interfaces communes plus restreintes ou refaire une partie de la roue a l’époque (on parle de Java 1.1.x et de Java 2 1.2 donc ça date). Donc une JFrame hérite de Frame qui est un composant de poids lourd, beaucoup plus proche des widgets natives qu'on pouvait trouver a l’époque. Le concept d'avoir un objet délégué qui soit le contrôle racine et fasse la mise en page a probablement du leur passer sous le nez a l’époque ou ne trouve pas d’équivalent sur tous les systèmes de fenêtrage natifs et que c’était plus simple de faire comme ça. Java a beau etre un bon exemple d'application massive de patrons de conception dans son API tout était loin d’être parfait surtout dans les toutes premières versions

[710dom]

Bonjour,

Merci pour la réponse.
J'ai été explorer JFrame.class et effectivement la méthode setLayout() a été redéfinie (elle existe déjà dans la classe Container) de cette façon:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
 
    /**
     * Sets the <code>LayoutManager</code>.
     * Overridden to conditionally forward the call to the
     * <code>contentPane</code>.
     * Refer to {@link javax.swing.RootPaneContainer} for
     * more information.
     *
     * @param manager the <code>LayoutManager</code>
     * @see #setRootPaneCheckingEnabled
     * @see javax.swing.RootPaneContainer
     */
    public void setLayout(LayoutManager manager) {
        if(isRootPaneCheckingEnabled()) {
            getContentPane().setLayout(manager);
        }
        else {
            super.setLayout(manager);
        }
    }

Et bingo, on applique bien le setLayout() sur le contentPane (j'ai vérifié pour add, c'est idem).
setRootPaneCheckingEnabled est lancé avec true par le constructeur de JFrame

Pour résumer JFrame hérite bien de Container et par la magie de la redéfinition, il applique le setLayout() sur son contentPane qui est également un Container.
A noter que l'on peut également appliquer un setLayout() sur un JPanel (puisque c'est aussi un Container), mais dans ce cas il n'y a pas redéfinition, c'est le setLayout() de la classe Container qui s'applique. Il convient dans ce cas de rajouter le JPanel au contentPane.

Encore merci pour ta réponse qui a été éclairante