Swing Best practise Tabbedpanes

[y0dA]

Bezüglich meinem kl. Testprojekt habe ich hier noch eine Frage bezüglich "best practise":
Ich möchte in meiner GUI 2 Tabbedpanes haben und als Inhalt jeweils ein paar JTextFields, JLists, Comboboxen etc. Wie ist hierbei die beste Herangehensweise? Im Detail:
-)soll ich das Gridbaglayout hierfür anwenden (Aufwand/Nutzen)?
-)legt man das Gridbaglayout dann auch über die Tabbedpanes oder habe ich innerhalb der Panels dann jeweils ein Gridbaglayout?
-) Macht man für jede Komponente (in dem Fall bspw. 2 Tabbespanes) jeweils eine eigene Klasse wo das Zeug reinkommt was sie eben beinhalten?

 

[hdi]

Was das Layout angeht kommt's halt drauf an wie genau deine Komponenten aussehen. GridBagLayout ist mächtig aber auch mächtig kompliziert (vergleichsweise). Oft reicht die Verschachtelung von ein paar Panels mit BorderLayout/FlowLayout.

Was die andere Frage betrifft: ich hab's mir inzwischen eig. angewöhnt alles für das Frame in eine einzige Klasse zu schreiben. Ist dann halt viel Code, aber es macht keinen Sinn das zu trennen da vorallem GUI Komponenten meist stark voneinander abhängig sind, und du musst dann halt etliche Dinge von der ersten an die zweite Klasse übergeben und andersrum.. Ist finde ich weitaus irritierender als paar mehr Zeilen Code in einer Klasse, wo alles beisammen ist.

Auslagern in eigene Klassen tue ich nur dann wenn es echt abgeschlossene, vom Rest der GUI mehr oder weniger unabhängige Dinge sind und ich die Kommunikation sinnvoll durch Listener lösen kann. Wenn ich merke das hängt zu stark vom Rest ab lass ich's aber mit dem ganzen anderen Haufen in meiner Frame-Klasse.

 

[Marcinek]

Ich würde das Layout auf keinen Fall vorgeben. Sollen doch die Panes entscheiden, was sie da drauf machen wollen.

Was die andere Frage betrifft: ich hab's mir inzwischen eig. angewöhnt alles für das Frame in eine einzige Klasse zu schreiben. Ist dann halt viel Code, aber es macht keinen Sinn das zu trennen da vorallem GUI Komponenten meist stark voneinander abhängig sind, und du musst dann halt etliche Dinge von der ersten an die zweite Klasse übergeben und andersrum.. Ist finde ich weitaus irritierender als paar mehr Zeilen Code in einer Klasse, wo alles beisammen ist.

Auslagern in eigene Klassen tue ich nur dann wenn es echt abgeschlossene, vom Rest der GUI mehr oder weniger unabhängige Dinge sind und ich die Kommunikation sinnvoll durch Listener lösen kann. Wenn ich merke das hängt zu stark vom Rest ab lass ich's aber mit dem ganzen anderen Haufen in meiner Frame-Klasse.

Sorry, aber das ist ein Beispiel von worst-practise.

Allein die Aussage zum starken Zusammenhang ist hier wohl gänzlich unpassend.

 

[y0dA]

Ich würde das Layout auf keinen Fall vorgeben. Sollen doch die Panes entscheiden, was sie da drauf machen wollen.

Also du meinst in jedem Pane ein eigenes Layout und für jede Pane eine eigene Klasse?

 

[Marcinek]

Wenn du das in irgendeiner weise anpassbar / Konfigurierbar und skalierbar halten willst, dann ein klares

JA!!

Alle anderen Lösungen kannst du für deine ein mann/frau Homeprojekte benutzen

 

[hdi]

@Marcinek

Ist nicht so dass ich es nicht schon anders versucht hätte. Fakt ist dass sich so Dinge wie Textfelder, Comboboxen und Buttons oft auf andere Komponenten auswirken. Textfeld A ist leer -> Button B wird disabled. Button C wird geklickt -> es wird auf Tab1 gewechselt. Usw.

Ich weiß die OOP sieht möglichst viele Klassen usw vor. Aber bei GUI's verschlimmbessert man das dann oft.. Wo Dinge nun mal krass zusammenhängen sollten sie zusammen bleiben.

Du kannst mir gerne ne komplexe GUI schicken wo alles schön sauber getrennt ist. Das würd ich gerne mal sehen, das ist jetzt auch nicht provokant gemeint sondern mein Ernst! Ich hab bisher allerdings noch keinen GUI-Code gesehen wo nicht jeder Konstruktor als Parameter 5 andere Elemente der GUI annehmen muss oder man 12 Listener hat die auch nicht mehr Sinn machen da es eh nur eine Instanz gibt die das implementiert...

Also "ein ganz klares JA!!", naja..

Sag mir mal was jetzt toller dran ist wenn er Tab1 und Tab2 in eigenen Klassen hat. Inwiefern bitte wirkt sich das auf die LayoutManager aus? Die kannste genauso ändenr wenn beide Tabs in einer Klasse liegen. Hast einfach nur Code aus einer in zwei Dateien gepackt. Das ist nicht der wahre Sinn von OOP, das ist nur für Leute deren Scrollrad an der Maus kaputt ist

edit: Schon mal den Source Code von den Swing-Komponenten gesehen? ~1000 Zeilen Code im Schnitt. Ganz einfach deswegen weil vieles zusammenhängt und sie keine Lust hatten alles ständig hin und her zu reichen. Deshalb meinte ich, nur auskoppeln wenn es wirklich unabhängig davon ist. Wenn du für dein Frame ne eigene Komponente machen willst, zB nen ColorPicker oder so, ja klar das kommt in ne eigene Klasse. Hat ja aber auch gar nix mit dieser konkreten GUI und der Logik der Komponenten zu tun.

 

[Marcinek]

Wenn es für dich nicht mehr als ein Code in andere Dateien auslagern ist, dann kann ich hier leider nix aufführen. Möchte ich unter diesen Bedingungen auch nicht.

Ich würde dir sehr gerne mein Projekt zeigen und dann würdest du sofort deinen Ansatz als unzureichend einsehen.

 

[hdi]

Dann bitte zeig mir dein Projekt