JTextfield Model

[earlgrey_tea]

Hallo an alle,

Frage
Hat ein JTextfield ein Model?

Warum ich das brauche
In meinem Programm -- eine simple Anwendung, die aus einer Tabelleneingabe ein berechnetes Ergebnis in oben besagtes Textfeld schreibt -- möchte ich gerne nach MVC trennen.
Im Fall der von mir verwendeten Tabellen, ComboBoxen, etc. funktioniert das auch ganz gut, da ich dort im Controller auf die jeweiligen Models zugreifen kann. Um den Code sauber zu halten, möchte ich beim JTextfield genauso verfahren.

Habt ihr Vorschläge, wie das geht?

 

[vanny]

Das Jtextfield hat ein Document als Model, soweit ich mich entsinne .

Gruß Vanny

 

[earlgrey_tea]

Das hab ich der API auch gelesen, das Problem dabei ist jedoch, dass das ein Interface ist, d.h. ich müsste komplett ein eigenes Model schreiben. Beim Document ist das auch nicht gerade trivial, wenn ich mir die API anschaue.

Ich hatte gehofft, dass es sowas wie ein DefaultDocument Model oder Vergleichbares, existiert.

Update:

Ich habs nun folgendermaßen gelöst (und getestet 🙂):

import javax.swing.text.BadLocationException;
import javax.swing.text.PlainDocument;

public class TextFieldModel extends PlainDocument {
	
	public void setText(String text) {
		try {
            super.remove(0, super.getLength()); 
			super.insertString(0, text, null);
		} catch (BadLocationException e) {
			e.printStackTrace();
		} 
	}
	public String getText() {
		String rueckgabe = ""; 
		try {
			rueckgabe = super.getText(0, super.getLength());
		} catch (BadLocationException e) {
			e.printStackTrace();
		}
		return rueckgabe; 
	}
}

 

[Gast2]

Welchen Mehrnutzen hat jetzt dein Document im Gegensatz zu den fertigen Document Models? Warum nimmst du kein fertiges?

 

[earlgrey_tea]

So hab ich nur drei Methoden: set, get und clear (ist hier nicht mit bei). Ich finde das komfortabler. Die Methoden des PlainDocument versauen irgendwie den Code. Ich finde es besser, man kapselt es.

Kurzum: Der Quellcode im Controller bleibt auf diese Art IMHO lesbarer und intuitiver.

 

[Gast2]

So hab ich nur drei Methoden: set, get und clear (ist hier nicht mit bei). Ich finde das komfortabler. Die Methoden des PlainDocument versauen irgendwie den Code. Ich finde es besser, man kapselt es.

Kurzum: Der Quellcode im Controller bleibt auf diese Art IMHO lesbarer und intuitiver.

He macht wenig Sinn genauso wie dein Document kein Sinn macht ???:L

 

[earlgrey_tea]

Kannst du das vielleicht ein wenig erläutern? So kann ich mit deinem Hinweis wenig anfangen. Meiner Ansicht nach sind nun View (JTextField) und Model (PlainDocument) sauber voneinander getrennt. Hätte ich das nicht gemacht, müsste ich eine Referenz auf das JTextField durch den gesamten Programmcode reichen.

Weiterhelfen würden mir:

• Ein knappes Beispiel
• Etwas mehr Details bei deiner Kritik (Was ist konkret an der Verwendung des Documents sinnlos?)

Vielen Dank.

 

[Gast2]

Ja ich versteh den Grund nicht warum du ein eigenes Document braucht?
1. Das JTextfield hat doch genau solche Methoden?
2. Warum greifst du überhaupt direkt auf Model zu? Es gibt als Controller auch den DocumentListener, wenn du was im Model manipulieren willst...
3. Willst jetzt jedem deiner Textfelder das Document setzen?
4 Zeig mal Code was du überhaupt vorhast und wie du darauf zugreifst

 

[Harry Kane]

Der Sinn von tea´s Document besteht offenbar darin, die Methoden zum Lesen und Schreiben von Text möglichst einfach zu halten, und das exception handling in das Document auszulagern anstatt es überall dort tun zu müssen, wo der Documentinhalt geändert wird (einen try-catch Block statt mehrerer).
@earlgrey_tea: auch ohne dein Model sind View und Model beim JTextField sauber getrennt. Du machst es nicht grundsätzlich "sauberer".
@SirWayne: Offenbar will tea sein Document in mehreren Textfeldern verwenden. Und da er seine Textfelder sowieso instanziieren muss, kann er bei der Gelegenheit gleich sein Document im ctor übergeben.

Es gibt als Controller auch den DocumentListener, wenn du was im Model manipulieren willst...

:bahnhof: Einen DocumentListener sollte man definitiv nicht verwenden, wenn man "was im Model manipulieren will", sondern dann, wenn man darüber informiert werden will, wem jemand was im Model manipuliert hat.

 

[Gast2]

:bahnhof: Einen DocumentListener sollte man definitiv nicht verwenden, wenn man "was im Model manipulieren will", sondern dann, wenn man darüber informiert werden will, wem jemand was im Model manipuliert hat.

Richtig darauf kann reagieren und eben eventuell was im Model ändern, ich hab ja kein Plan was er vorhat, ich seh immer noch keinen Vorteil von seinem tollen Dokument

 

[bERt0r]

In meinem Programm -- eine simple Anwendung, die aus einer Tabelleneingabe ein berechnetes Ergebnis in oben besagtes Textfeld schreibt -- möchte ich gerne nach MVC trennen.
Im Fall der von mir verwendeten Tabellen, ComboBoxen, etc. funktioniert das auch ganz gut, da ich dort im Controller auf die jeweiligen Models zugreifen kann. Um den Code sauber zu halten, möchte ich beim JTextfield genauso verfahren.

Für mich macht das den Eindruck als will der TO einfach blind sein MVC Dogma umsetzen, ohne eigentlich zu wissen um was es bei dem Pattern geht. Wie man hier ganz gut sieht verwendet Swing eigentlich nicht das typische MVC, eben weil es nicht das Maß aller Dinge ist.
Du kannst bei einem JTextField mit setText und getText genau das selbe machen wie mit deinem Document. Warum machst du dir die Arbeit? Es wird dadurch nicht übersichtlicher oder strukturierter. Es wird eher unübersichtlicher, weil jemand der dienen Code liest dann noch eine Klasse mehr lesen muss.
Codetrennung, Aufteilung und Strukturierung ist wichtig, ebenso wichtig ist aber auch, dass man weiß wieso man etwas aufteilt.

 

[earlgrey_tea]

Angeregte Diskussion 😀

Für mich macht das den Eindruck als will der TO einfach blind sein MVC Dogma umsetzen, ohne eigentlich zu wissen um was es bei dem Pattern geht.
[...]
Codetrennung, Aufteilung und Strukturierung ist wichtig, ebenso wichtig ist aber auch, dass man weiß wieso man etwas aufteilt.

Ich weiß ganz gut, dass Patterns einem auch wundervoll im Weg stehen können und nicht das Maß aller Dinge sind. Da ich jedoch für meine beiden Tabellen und meine ComboBox jeweils schon ein eigenes Model schreiben musste und diese im Controller erzeuge, bot es sich meiner Meinung nach an, das auch für das einzige verbliebene Element -- das JTextField -- ebenfalls umzusetzen.

Aufbauend auf den Hinweisen von Harry_Kane, und SirWayne und dem Link von bERt0r hab ich das PlainDocument nun wieder entfernt. Ich erzeuge jetzt das JTextField im Controller und reiche eine Referenz darauf in die View weiter.

Gut ich werd mich dann mal in die Lektüre zur Swing Architektur stürzen. Hat jemand von euch vielleicht einen Artikel/ ein Buch zu gutem Softwaredesign an der Hand, um solche Designschwächen zu vermeiden?

 

[bERt0r]

Warnung: Ich bin grade alkoholisiert.
Mir ist bewusst, dass ich ziemlich deutlich mit meiner Äußerung vorhin war. Das Forum ist mMn ja genau dafür da, Probleme deiner Art zu lösen. Dir mangelt es wirklich nicht an einem guten Buch über Softwaredesign. Vielleicht irre ich mich, aber mMn kann man das nur durch Erfahrung wirklich lernen.
Im Großen und Ganzen geht es darum, sein eigenes Hirn zu gebrauchen und zu hinterfragen warum es ein bestimmtes Pattern gibt. Nur wenn man begründen kann, warum ein Pattern Sinn macht, beherrst man es auch wirklich. Deshalb solltest du nie blind ein Pattern befolgen, sondern immer in der Reihenfolge vorgehen: was ist meine Aufgabe, wie kann ich sie Erfüllen, gibt es ein Pattern dafür?
Du hast bei mir den Eindruck erweckt: Ich verwende bei meiner ComboBox und meiner JTable das MVC Pattern und will dieses Pattern jetzt für mein Textfield verwenden, koste es was es wolle.

 

[Gast2]

Ich weiß ganz gut, dass Patterns einem auch wundervoll im Weg stehen können und nicht das Maß aller Dinge sind. Da ich jedoch für meine beiden Tabellen und meine ComboBox jeweils schon ein eigenes Model schreiben musste und diese im Controller erzeuge, bot es sich meiner Meinung nach an, das auch für das einzige verbliebene Element -- das JTextField -- ebenfalls umzusetzen.

Du kannst Tabellen,Trees, Comboboxen doch nicht mit einer Checkbox, Textfeld Textarea oder sonstigem Vergleichen. In Tabellen und Trees stellst du meistens Objekte dar, in den anderen Widgets eher einfachere Sachen.

Was genau so wichtig ist, ist ein gutes Databinding zwischen deinem (Domain) Model und den Widgets zu machen. Da halte dich lieber nicht mir so Kleinigkeiten auf wie ein Dokument zu schreiben.

 

[earlgrey_tea]

Mir ist bewusst, dass ich ziemlich deutlich mit meiner Äußerung vorhin war.

Och, da kenn ich andere Foren... ;-)

Du hast bei mir den Eindruck erweckt: Ich verwende bei meiner ComboBox und meiner JTable das MVC Pattern und will dieses Pattern jetzt für mein Textfield verwenden, koste es was es wolle.

Hmmm, es könnte sein, dass der Eindruck nicht ganz unbegründet war.

Was genau so wichtig ist, ist ein gutes Databinding zwischen deinem (Domain) Model und den Widgets zu machen. Da halte dich lieber nicht mir so Kleinigkeiten auf wie ein Dokument zu schreiben.

Das ist mal nen Wort.

Wie auch immer, ich nehm die Diskussion zum Anslass auch meine anderen Programme auf den Prüfstand zu zerren und zu schauen, ob ich da vielleicht ein wenig zu tief in die Patternkiste geschaut hab.