[JavaFX] Welche Methode zum Setzen der Events für Objekte?

Sollten Methoden in der Controller.java-Klasse aufgerufen werden (1) oder sollten die Events in der Methode initialize hinzugefügt werden (2)?

(1) Setzen im SceneBuilder:

Controller.java:

dasIstEineMethodeTextField1(MouseEvent e){
textField1.selectAll();
}

dasIstEineMethodeTextField2(MouseEvent e){
textField2.selectAll();
}
...

Angenommen, ich möchte für 10 TextField die Funktion einbauen, dass der jeweilige Text markiert werden soll. Dann muss ich für jedes TextField eine eigene Methode schreiben oder in einer Methode abfragen, welches TextField angeklickt wurde.

(2):

public void initialize(URL url, ResourceBundle rb) {
textField1.setOnMouseClicked(mouseEvent -> {
textField1.selectAll();
...
});

textField2.setOnMouseClicked(mouseEvent -> {
textField2.selectAll();
...
});
}

Wenn ich jetzt aber drei Events für 10 TextField habe, muss ich hier jedes Mal das Event per Hand hinzufügen.

Welche Methode eignet sich also für mehr Übersichtlichkeit oder so, wenn mehrere Events für mehrere z. B. TextFelder registriert werden müssen?

Answer 1

[regex9]

Dann muss ich für jedes TextField eine eigene Methode schreiben oder in einer Methode abfragen, welches TextField angeklickt wurde.

Nein. Das Event-Objekt beinhaltet Informationen zu dem Event, wozu auch das auslösende Element gehört.

TextField textField = (TextField) e.getSource();
textField.selectAll();

Sofern sich die auszuführende Logik zwischen den zu beobachtenden Komponenten nicht allzu sehr unterscheidet, genügt ein einziger Handler.

Convenience Methoden (wie z.B. setOnMouseClicked) würde ich im Backend nach Möglichkeit nur sehr sparsam verwenden. Wenn es sich nur um ein einziges Element handelt, dem eine individuelle Aktion zugeordnet werden soll und sich die Logik in kurzer Form (max. 2-3 Zeilen) formulieren lässt, mag es ok sein.

Ein klassisches Beispiel:

greetingsButton.setOnAction(event -> System.out.println("Hello world!"));

Du hast eine sehr einfache Aktion, die so nur einmal vorkommt.

Umso öfter du solche Blöcke allerdings hast, umso schneller wächst die Anzahl an Codezeilen und du verlierst an Übersicht. Letzten Endes sammelst du unter Umständen ja mehrere verschiedene Logiken / Aktionen unterschiedlichen Zwecks in einer Methode.

Entsprechende Attribute im FXML-Code sind da praktischer.

<Button onAction="#doSomething">Click me</Button>

Sollte die Anzahl an Methoden im Controller zu groß werden, wäre es an der Zeit, sich zu überlegen, ob man die Klasse / das View nicht besser aufsplittet. Der Controller könnte für Hilfsmethoden beispielsweise eine Helferklasse zur Seite gestellt bekommen und wenn man das View zerlegt, zerlegt man in dem Zuge ebenso den Controller in verschiedene kleinere Controller-Klassen.

Comments

[verreisterNutzer]

Danke!

Ist das das, was du mit aufsplitten meinst?

Ist das auch einfach so machbar, wenn ich statt Tabs AnchorPanes verwende? Ich habe nur ein Fenster, was nicht mehrere Seiten hat.

[regex9]

@verreisterNutzer

Ja, das meine ich. Ein Programm - nimm nur Eclipse oder IntelliJ als Beispiel, teilt sich öfter in verschiedene Arbeitsbereiche/Dialoge/Panels auf (Projekt Explorer, Code-Editor, Konsolenfenster, etc.) auf. Jeder dieser Bereiche hat ein eigenes View, ein eigenes Model und mindestens einen eigenen Controller. Wenn ein Bereich zu komplex wird, wird er aufgeteilt. Jeder Teil bekommt wieder sein eigenes View, Model, etc.. Bei einer Zweiteilung hättest du dann also eine FXML, die beide Teile einbindet und zwei FXML, die jeweils einen Teil beschreiben.

Tabs brauchst du dafür nicht. Es reicht ein Container, der Platz bietet. Schau hier: Nested Controllers. Ebenso kannst du dir eigene Komponenten bauen, indem du von bestehenden erbst (siehe hier).

[verreisterNutzer]

@regex9

Ich danke dir!

Ich denke, ich habe es hinbekommen, dies umzusetzen. Jetzt muss ich nur noch die ganzen Objekte neu einteilen.

[verreisterNutzer]

@regex9

Wann brauche ich denn eigene Container? Ich sehe jedenfalls keinen Grund. 🤔

[regex9]

@verreisterNutzer

Eine Aufteilung ist in zwei Fällen förderlich:

• Für eine logische Aufteilung des Programms (Bsp. Eclipse: Projektexplorer, Code-Editor, etc. sind einzelne Komponenten/Module, da sie in erster Linie unabhängig voneinander agieren können).
• Wenn, wie schon geschrieben, der Controller / die View zu komplex werden. Es gibt verschiedene Quellen, die verschiedene Richtwerte vorschlagen (z.B. max. 30 Methoden oder max. 5-7 öffentliche Methoden, ...), doch ich denke, das erkennt man selbst schon, wann es auf jeden Fall zu viel wird.