# JTextfield Model



## earlgrey_tea (14. Jun 2012)

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 (14. Jun 2012)

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

Gruß Vanny


----------



## earlgrey_tea (14. Jun 2012)

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 (14. Jun 2012)

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


----------



## earlgrey_tea (14. Jun 2012)

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 (15. Jun 2012)

earlgrey_tea hat gesagt.:


> 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 (15. Jun 2012)

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 (15. Jun 2012)

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 (15. Jun 2012)

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.


			
				Sir Wayne hat gesagt.:
			
		

> 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 (15. Jun 2012)

Harry Kane hat gesagt.:


> :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 (15. Jun 2012)

> 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 (15. Jun 2012)

Angeregte Diskussion 



bERt0r hat gesagt.:


> 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 (16. Jun 2012)

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 (16. Jun 2012)

earlgrey_tea hat gesagt.:


> 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 (16. Jun 2012)

bERt0r hat gesagt.:
			
		

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


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



			
				bERt0r hat gesagt.:
			
		

> 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. 



			
				SirWayne hat gesagt.:
			
		

> 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.


----------

