Swing Designfrage

[kaoZ]

Hallöchen ich arbeite mich grade in die Layoutmanager von Swing ein und habe eine kleine frage zum "designen" von anwendungen, und zwar gehts mir vorwiegend sauberen und leicht verständlichen Code zu schreiben, deshalb die Frage wie würdet ihr z.B dieses Frame erstellen, ohne es von JFrame etc. abzuleiten :

Spoiler

package de.kaoZ.dialogViews;

import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.Insets;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BorderFactory;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JTextField;

import de.kaoZ.user.User;

	/**
	 * 
	 * @author kaoZ
	 * @version 1.0
	 */

public class UserView implements IView{
	
	User user;
	
	JFrame frame;
	JLabel infoLabel, userLabel,companyLabel, addressLabel, streetLabel , telLabel;
	JTextField username, company, address, street, tel;
	JPanel panelOne,panelTwo, panelThree;
	JButton okBtn;
	
	GridBagConstraints gbc;
	
	public UserView() {
		initFrame();
	}

	private void initFrame() {
		//Frame
		frame = new JFrame("Rechnungs Editor v1.0");
		frame.setSize(500,400);
		frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
		frame.setResizable(false);
		frame.setLocationRelativeTo(null);
		
		//Layout Components
		gbc = new GridBagConstraints();
		gbc.insets = new Insets(5,5,5,5);
		
		//Panel
		panelOne = new JPanel();
		panelOne.setBorder(BorderFactory.createEmptyBorder(20,10,0,10));
		
		panelTwo = new JPanel(new GridBagLayout());
		panelTwo.setBorder(BorderFactory.createEmptyBorder(0,20,10,50));
		
		panelThree = new JPanel();
		panelThree.setBorder(BorderFactory.createEmptyBorder(0,0,10,0));
		
		//Buttons
		okBtn = new JButton(" Einrichtung Abschließen ");
		okBtn.addActionListener(new ActionListener() {
			
			@Override
			public void actionPerformed(ActionEvent e) {
				// TODO Automatisch generierter Methodenstub
				
			}
		});
		
		//Label for panelOne
		infoLabel = new JLabel("Bitte geben Sie hier Ihre Daten ein :");
		
		//Set Grid Positions for panelTwo
		userLabel = new JLabel("Inhaber :");
		gbc.gridx = 0;
		gbc.gridy = 1;
		gbc.anchor = GridBagConstraints.WEST;
		panelTwo.add(userLabel,gbc);
	
		username = new JTextField();
		gbc.gridx = 0;
		gbc.gridy = 2;
		username.setPreferredSize(new Dimension(200,25));
		gbc.fill = GridBagConstraints.HORIZONTAL;
		panelTwo.add(username,gbc);
		
		companyLabel = new JLabel("Firma :");
		gbc.gridx = 0;
		gbc.gridy = 3;
		panelTwo.add(companyLabel,gbc);
		
		company = new JTextField();
		company.setPreferredSize(new Dimension(200,25));
		gbc.gridx = 0;
		gbc.gridy = 4;
		panelTwo.add(company,gbc);
		
		addressLabel = new JLabel("PLZ/Ort :");
		gbc.gridx = 0;
		gbc.gridy = 5;
		panelTwo.add(addressLabel,gbc);
		
		address = new JTextField();
		address.setPreferredSize(new Dimension(200,25));
		gbc.gridx = 0;
		gbc.gridy = 6;
		panelTwo.add(address,gbc);
		
		streetLabel = new JLabel("Straße/Hausnummer :");
		gbc.gridx = 0;
		gbc.gridy = 7;
		panelTwo.add(streetLabel,gbc);
		
		street = new JTextField();
		street.setPreferredSize(new Dimension(200,25));
		gbc.gridx = 0;
		gbc.gridy = 8;
		panelTwo.add(street,gbc);
		
				
		//Add Components to Frame
		panelOne.add(infoLabel);
		panelThree.add(okBtn);
		
		frame.add(BorderLayout.PAGE_START, panelOne);
		frame.add(BorderLayout.LINE_START, panelTwo);
		frame.add(BorderLayout.PAGE_END, panelThree);
		
	}

	@Override
	public void show() {
		frame.setVisible(true);
		
	}
}

Über Anregungen andere Layoutmanager zu nutzen oder allgemein saubereren Code zu schreiben bin ich schon mal vorab dankbar, gern auch Anregungen bei Code doppelung etc.

immer her mit der konstruktiven Kritik opcorn:

 

[Gucky]

Warum möchtest du deine Klasse nicht von JFrame ableiten? Das wäre eigentlich das Gängige, eine Klasse deine Klasse erweitern zu lassen und dort die Einstellungen vorzunehmen.
Ich halte es für am saubersten die GUI in einer abgeleiteten Klasse zu erstellen.

Und ich halte es für sauberer die gesamte GUI nicht in einer Methode zu erstellen sondern die einzelnen Komponenten in privaten Methoden zu erstellen. Das macht das Ganze übersichtlicher.

 

[kaoZ]

Danke schonmal für den Ansatz , ich werde es mal umsetzen und hier das Ergebnis posten, aber jetzt mal rein vom Ansatz her , hättest du es ebenfalls mit dem GridBagLayout gelöst oder gibt es einfachere/sauberer alternativen um das Frame so darzustellen ?

 

[Gucky]

Mit LayoutManagern habe ich mich noch nie so viel beschäftigt, muss ich leider gestehen aber vielleicht wäre das GroupLayout noch etwas für dich. Andernfalls guck mal hier.

 

[turtle]

Warum möchtest du deine Klasse nicht von JFrame ableiten?

Das scheint wirklich oft gemacht zu werden und ich werde nie begreifen wo der Vorteil ist. Ich wiederspreche nur ungern meinem Freund Gucky, aber...

Ableiten macht man, wenn man in der abgeleiteteten Klasse "etwas" anders machen möchte, als in der Vaterklasse. Das ist aber hier praktisch nie der Fall. Meistens wird folgender Code gebraucht.

		JFrame frame = new JFrame("<XXX>");
		frame.setLayout(new BorderLayout());
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.add(new Klasse(), BorderLayout.CENTER);
		frame.pack();
		frame.setVisible(true);

Hier siehst du eigentlich nur Einstellungen am frame, aber nirgends ist es notwendig dafür von JFrame zu erben.

Aber die GUI im Frame steckt in einem JPanel und ich erbe daher immer davon. Ich zeige ja auch eigen Controls im Panel an und oft habe ich verschiedene Listener definiert, die auf das Verhalten im JPanel reagieren. Daher sehen meine Swing Klassen so aus und es macht Sinn das andere Verhalten in einer Kindklasse von JPanel zu definieren:

public class MeinPanel extends JPanel {
	public MeinPanel () {
		add(new JLabel("Test Label", BorderLayout.CENTER);
	}

	public static void main(String[] args) {
Frame frame = new JFrame("<XXX>");
		frame.setLayout(new BorderLayout());
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
                frame.add(new MeinPanel (), BorderLayout.CENTER);
		frame.pack();
		frame.setVisible(true);
}

PS: Ich lese gerade noch, das über verschiedene Layout-Manager diskitiert wurde. Ich gebe zu, das ich das Verschachteln mehrer Manager (Gridbag-, Border-, Flow-Layout) nie ganz verstanden habe. Ich nehme immer (und ausschließlich) den com.jgoodies.forms.layout.FormLayout Manager. Dieser wird vorzüglich vom WindowBuilder (Swing Designer) in Eclipse unterstützt.

 

[kaoZ]

Ableiten wollte ich nicht weil es ansich für mich keine Vorteile gibt wenn ich eine Unterklasse von JFrame erstelle.

(Abgesehen von der Klasse , dessen JFrame inhalt ich später Drucken möchte)

da ich lediglich, wie auch turtle schon geschrieben hat nur Einstellungen vornehme, zumindes am Frame selbst.

Ausserdem dachte ich eigentlich,das man laut OO-prinzipien die Komposition der Vererbung vorziehen soll?!

Die verschiedenen Layoutmanager eigne ich mir grade an , ich bin kein freund von per Builder "zusammengezimmerten" Gui's, bzw. würde ich gerne erst alles Stück für Stück erlernen eh ich den einfachen/einfacheren Weg über einen Swing-Builder wähle

Schließlich will ich das Hintergrundwissen haben , um auch Situationen unter Kontrolle zu bringen/ bringen zu können, ohne auf wiederrum externe Tools zugreifen zu müssen :rtfm:

Mir ging es eigentlich darum von Anfang an sauberen , verständlichen, und vorallem Flexiblen/Erweiterbaren Code zu schreiben den auch andere ohne große mühe lesen können, ich bin der Meinung das macht es mir später selber leichter eventuelle Fehler und Hindernisse leichter zu finden und Lösungen dafür erstellen

[EDIT]
Wenn du sagst du würdest das initialisieren bzw. das einrichten des Frames nicht in einer Methode erledigen, wo würde man am besten aufteilen ? eine Methode für das Frame , eine für das JPanel? oder sogar noch getrennter ? vielleicht doch mit Initialisierungsblock ?
[/EDIT]

 

[Gucky]

Meinst du mit dem EDIT mich?

Also ich würde sowas wie:

private JPanel getJPanel1(){
   if (jPanel1==null){
      jPanel1 = new JPanel();
      //deine Einstellungen
   }
   return jPanel1;
}

Und dann im Initialize:

jContentPane.add(getJPanel1() );

EDIT: Das Ableiten von JFrame mache ich immer, weil eclipse mir das mit einer visual class immer so hinbastelt

 

[kaoZ]

Meinst du mit dem EDIT mich?

jap

aber mal abgesehen davon, nehmen wir an ich möchte einen Dialog zum einrichten eines Programmes erstellen, , das image oben im post gehört mit zu einem der Frames des Dialoges, wie würdet ihr dieses angehen ?

meine herangehensweise ist zzt. folgende :

1. package im Projekt erstellen (sagen wir mal de.kaoZ.setupDialog)

1a. Interface für die folgenden Views erstellen ( 1 Methode (zum Anzeigen) / 1 Konstante für den Titel )

2. Klasse für einen Willkommens Dialog erstellen (z.B WelcomeView )
-beinhaltet lediglich eine JTextArea und einen JButton der das SetupView startet

3. Klasse für den View erstellen (z.B SetupView ) inhalt ähnlich dem bild oben
-Legt Userdaten Fest , ( hier könnte man ja eigentlich die Addressdaten auch wieder in eine eigene Klasse auslagern zwecks Kohäsion (z.B Address)

4. Klasse User erstellen , die Daten beinhaltet wie Name, Firma etc.

macht es jetzt Sinn die verschiedenen Frames ( oder Panels ) für die Views von einer Oberklasse abzuleiten ( sagen wir DialogViews ) ? an und für sich eigentlich schon oder ? wobei ich ja bereits ein Interface erstellt habe, welches von den einzelnen Klassen implementiert wird ? oder wäre hier eine Abstrakte klasse angebrachter als ein Interface ?

 

[turtle]

einen Dialog zum einrichten eines Programmes

Wenn ich das richtig verstehe, würdest du mit 1-2 Interfaces und 2 Klassen für einen Dialog starten?

Ich bin zwar auch dafür, ein "Projekt" zu strukturieren, aber...

Ich behaupte, mit einem Interface oder abstrakten Klasse wird es wenig bringen, da ich glaube, dass es keine weiteren Implementierungen oder Realisierungsklassen als eine geben wird.

Daher würde ich eine JDialog-Klasse erstellen (SetupDialog) und diese verwenden.

 

[kaoZ]

Das Interface soll eigentlich von allen Views in dem Programm implementiert werden , um allen die Konstante und die Methode zum anzeigen zur verfügung zu stellen , deswegen viel meine wahl auf ein Interface, als schnittstelle zwischen ganzen Gui Elementen.

 

[turtle]

Das Interface soll eigentlich von allen Views in dem Programm implementiert werden

Echt? Du hast mehrere Setup-Dialoge?

 

[kaoZ]

So in der Art :



Wäre der Erste (Willkommens)Dialog,

daraufhin folgt der Dialog zur Einrichtung des Nutzers,




und abschließend noch einer zur Einrichtung des Haupt Programms, wie z.B zum setzen des Speicherpfades, voreinstellungen usw.

deswegen sollte jedem dieser Views die Methode des Interfaces und die Konstante zur verfügung stehen.

so war zumindest mein ansatz

[EDIT]Wer Schreibfehler findet , darf sie behalten [/EDIT]

 

[kaoZ]

Wie würdest du so etwas umsetzen Turtle ?

 

[Gucky]

Vielleicht wäre das CardLayout was für dich. Und dann gibt es noch ein bestimmtes Panel, dass mehrere Registerkarten haben kann. Das wäre vielleicht auch was.

 

[MrClave]

Mir ging es eigentlich darum von Anfang an sauberen , verständlichen, und vorallem Flexiblen/Erweiterbaren Code zu schreiben

Ist schon richtig so zu denken, allerdings musst du auch überlegen, inwiefern sich dieser Code ändern könnte.
Was für Komponenten könnten denn im späteren Verlauf hinzu kommen?
Lohnt sich der Aufwand, etwas so perfekt zu strukturieren, obwohl es sich eigentlich nicht großartig ändern wird?

GUI-Code guckt sich denke ich allgemein niemand im Detail an, daher wäre es non-sense hier viel Zeit zu investieren.
Und falls jemand den Code nicht versteht, kann man ihm immer noch ein klassisches Klassendiagram vor die Nase halten. Oder evt. andere Diagramme.

-------------------

Ich erstelle meist zu jedem Objekt, welches visualisiert werden soll, eine Klasse, welche dann von JPanel erbt *. Ich benenne sie meist wie das darzustellende Objekt + Component am Ende. Damit bin ich immer sicher, dass es sich bei dieser Klasse um die GUI-Komponente von Objekt XY handelt.
In dieser besagten Klasse erzeuge ich dann die notwendigen Textfelder, Labels, Buttons, etc., um die Informationen dem Benutzer zugänglich zu machen.
Dabei teile ich die Schritte gerne in private Methoden auf, welche der Konstruktor dann nacheinander aufruft.

• initComponents() - Alles initialisieren
• setupComponents() - Alles konfigurieren. LayoutManager, Border, etc.
• addingComponent() - Alles dem Haupt-, bzw. einem anderen Unterpanel hinzufügen

Im letzten Projekt hatte ich dazu noch eine Superklasse für alle GUI-Komponenten, welche ich dann stattdessen von JPanel erben ließ.
Da in diesem Projekt die Internationalisierung von hoher Bedeutung war, enthielt die Superklasse entsprechende Felder.

• ResourceBundle - Notwendig für die verschiedenen Sprachen
• Properties - Für Einstellungen wie standard Sprache, Font-family, Font-size, etc.

Mit diesem Aufbau ist man schon ein gutes Stück flexibel.

• Das Hauptfenster interessiert sich nicht dafür, was ihm konkret hinzugefügt wird, da alles als JPanel behandelt wird.
• Ich hab' ein stabiles Fundament für alle GUI-Komponenten.
• Wenn eine Änderung alle GUI-Komponenten betreffen soll, muss ich diese Änderung an nur einer Stelle vornehmen.

Natürlich ist das nicht perfekt, aber bei sowas mache ich immer Abstriche.
Man könnte hier vielleicht noch was mit dem Decorator und Composite Entwurfsmuster basteln, allerdings habe ich bisher nicht das verlangen danach gehabt.

* Anm. Es kommt natürlich auch vor, dass mehrere Objekte in eine gemeinsame Komponente passen. Da muss man halt ein wenig schauen, wie es am besten passt.

--------------------------

Was den ersten Dialog angeht, so sehe ich auf Anhieb ein BorderLayout, ein FlowLayout und ein GridLayout.

Oben und unten:

new FlowLayout(FlowLayout.CENTER);

Mitte links:

new GridLayout(1,8,10,10);

Hauptpanel:

new BorderLayout(20,20);

--------------------------

Ich würde zudem das CardLayout zum wechseln zwischen den verschiedenen Komponenten verwenden.

• Ist Benutzerfreundlich(er) (Niemand will, dass tausend Fenster aufploppen)
• Du kannst ohne Probleme hin und her switchen und neue Panels hinzufügen
• Falls du beständige Komponenten hast, sprich Komponenten, welche immer zu sehen sein sollen (eine Menubar, Toolbar, ...), brauchst du diese nicht für jedes Fenster erneut erzeugen, sondern nur einmal für das Hauptfenster

Das wäre mal meine Ansicht davon.
Manche werden mir den Vogel zeigen, manche werden's mögen...
Musst du gucken, ob es dir vielleicht geholfen hat.

 

[kaoZ]

Danke erstmal für deinen Ansatz, du sagtest du siehts beim ersten dialog direkt ein Flow, Grid und ein Borderlayout, ich habe diese allerdings so realisiert :

Spoiler

package de.kaoZ.setupViews;

import java.awt.Component;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.BorderFactory;
import javax.swing.Box;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JTextArea;

public class DialogView implements IView {
	
	JFrame frame;
	JLabel label;
	JTextArea area;
	JButton okBtn, declineBtn;
	
	Box vBox, hBox;
	
	public DialogView() {
		initFrame();
	}
	
	private void initFrame() {
		//Frame
		frame = new JFrame(TITLE);
		frame.setSize(350,200);
		frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
		frame.setResizable(false);
		frame.setLocationRelativeTo(null);
		
		//Box
		vBox = Box.createVerticalBox();
		hBox = Box.createHorizontalBox();
		
		//Label
		label = new JLabel("Willkommen zur Einrichtung");
		label.setAlignmentX(Component.CENTER_ALIGNMENT);
		
		//TextArea
		area = new JTextArea();
		area.setText("Dieser Assistent wird Sie durch die Einrichtung Ihres Programmes führen," +
				" bitte nehmen Sie Sich einen Augenblick zeit.");
		area.setWrapStyleWord(true);
		area.setLineWrap(true);
		area.setBackground(null);
		area.setEditable(false);
	
		
		
		//Button
		declineBtn = new JButton(" Abbrechen ");
		declineBtn.addActionListener(new ActionListener() {
			
			@Override
			public void actionPerformed(ActionEvent e) {
				System.exit(0);
				
			}
		});
		
		okBtn = new JButton(" Weiter ");
		okBtn.addActionListener(new ActionListener() {
			
			@Override
			public void actionPerformed(ActionEvent e) {
				frame.dispose();
				new UserView().show();
				
			
			}
		});
		
		//Add Components
		vBox.add(label);
		vBox.add(Box.createVerticalStrut(10));
		vBox.add(area);
		vBox.add(Box.createVerticalStrut(10));
		vBox.add(hBox);
		hBox.add(Box.createHorizontalGlue());
		hBox.add(declineBtn);
		hBox.add(Box.createHorizontalStrut(10));
		hBox.add(okBtn);
		vBox.setBorder(BorderFactory.createEmptyBorder(10,10,10,10));


		
		frame.add(vBox);
		
	}

	@Override
	public void show() {
		frame.setVisible(true);
		
	}

}

Gerne nehme ich Statements hierzu , das hilft mir von vorneherein gleich auf evtl. unsaubere Programmierung oder fehler zu achten

Hierzu noch mein Interface welches 2 Konstanten und die show() methode enthält:

package de.kaoZ.setupViews;

public interface IView {
	
	final static String TITLE = "Rechnungs Editor v1.0"; 
	final static String TEMPFILE = "C:/TempUser.txt";
	
	void show();

}

dies dient dazu jeder View bzw. Gui klasse ( für das Setup ) den Titel und den Pfad für den Tempfile zur erfassung der Daten die bei der einrichtung hinterlegt werden zugänglich zu machen.

Das mit dem CardLayout muss ich mir mal durch den kopf gehen lassen , an und für sich wollte ich es aufbauen wie man es von vielen anderen programmen kennt, zwecks nutzerdaten , AGB usw. wäre alles in allem 3-4 Fenster ( incl. JFileChooser) für die Auswahl des Pfades unter dem dann später die daten hinterlegt werden , danach öffnet sich ein kleines Fenster mit Progressbar ( nur der Optik wegen ), welches in einem anderen Thread den Dateipfad anlegt, die Nutzerdaten in einer Serialisierten Datei ablegt und das eigentliche Programm, bzw den Frame dafür einrichtet .

Da ich erst seit ca 6 Monaten Programmiere bin ich für jede art der Wegweisung offen :toll:

 

[turtle]

Ich möchte, obwohl Weihnachten ist, mal etwas Grundlegendes sagen. Ich weiß, das häufig Konstanten in Interfaces definiert werden, aber...

public interface IView {
    
    final static String TITLE = "Rechnungs Editor v1.0"; 
    final static String TEMPFILE = "C:/TempUser.txt";

Konstanten sind ein Implementierungsdetail (siehe auch Joshua Bloch hier). Dabei "leckt" das Implementierungsdetail in alle benutzenden Klassen. Dies könnte besser über

import static com.example.Constants.*;

gemacht werden.

Trotzdem weiterhin schönes Weihnachtsfest

 

[kaoZ]

Wenn ich jetzt in dem Interface aber jetzt ja die Methode deklariere welche in jeder DialogKlasse (Gui) verfügbar sein soll, ist es denn dann so tragisch wenn ich die Konstanten gleich mit in das Interface definiere ? Oder sollte man diese dann trotzdem , um Bad smells zu umgehen lieber in einer eigenen Klasse definieren und diese dann wie du eben beschrieben hast per statischem import einbinden ?

Wobei das ja wieder die Anzahl der Klassen erhöhen würde

[EDIT]Frohe Weihnachten [/EDIT]

 

[MrClave]

Wie gesagt, das ist nur das, was mir auf Anhieb in den Sinn kam.

Welchen LayoutManager du letzten Endes benutzt, ist ja egal. Das Resultat zählt.
Ich verwende allerdings fast ausschließlich das Border-, Grid- und FlowLayout, weil es nahezu überall passt. (Für komplexere GUIs müsste man halt etwas mit dem GridBagLayout basteln)


Bei dem Code wird wohl jedem direkt das fehlende 'private' in die Augen fallen.

Beim ActionListener würde ich keine anonyme Instanz verwenden, da dies bei mehreren Buttons schnell unlesbar wird.
Stattdessen würde ich entweder eine private innere Klasse erstellen, welche ActionListener implementiert, oder es ganz einfach DialogView implementieren lassen.

Oberflächen Texte würde ich dazu in Properties-Dateien schreiben und sie dementsprechend zu Programmbeginn laden, zwecks internationalisierung.
Genau so würde ich es mit dem Titel machen.

Aber diese Punkte habe ich ja bereits oben erwähnt.

------

Statt den Pfad zur Datei herumzureichen, würde ich eher eine Handlerklasse herumreichen, welche sich um das schreiben und lesen kümmert.
Damit sparst du dir das mehrfache laden der Datei und eventuelle Probleme mit Inhalten.
Den Pfad zur Datei würde ich in einer Controller Klasse definieren. Diese Klasse sagt der Handlerklasse dann auch, wann die sie Datei zu laden hat und um welche Datei es sich handelt. Außerdem reicht die Controllerklasse das Handlerobjekt an alle Objekte weiter, die es benötigen.

Falls du nicht verstehst was ich meine, werde ich dir später ein Beispiel zeigen.

Wobei das ja wieder die Anzahl der Klassen erhöhen würde

Die Anzahl der Klassen spielt keine Rolle. Schau dir die großen Systeme und Spiele an.
Da sind tausende Klassen im Spiel.

 

[kaoZ]

Da ich mich schon durch die Entwurfsmuster von Kopf bis Fuß gelesen habe kann ich mir grob vorstellen worauf du hinaus möchstest. (MVC)

Im Moment handhabe ich es so das ich einfach beim eingeben der Daten eine "temporäre" Datei erstelle, und am ende der der Setup Dialoge alles aus der Datei auslese und letztlich in serialisierter form zu Speicherung in dem Pfad den der User während der Einrichtung angegeben hat ablege, zudem hinterlege ich in der datei einen booleschen Wert da ich das Setup ja nur EINMAL und nicht bei jedem Programm start ausführen möchte.

Du meinst also ich soll mir eine Controllerklasse erstellen, welcher die lese und Schreibarbeit ausführt und dem ich lediglich ein Objekt(einer separaten Handler klasse, welche die Daten enthält, (Strasse, Username, Pfad, Adresse usw) übergebe ?Das würde mir zumindest das erstellen der Temporären Datei ersparen , insofern ich das Objekt der Handlerklasse den verschiedenen Views im konstuktor mitgebe^^

 

[kaoZ]

Oberflächen Texte würde ich dazu in Properties-Dateien schreiben und sie dementsprechend zu Programmbeginn laden, zwecks internationalisierung.
Genau so würde ich es mit dem Titel machen.

Du meinst XML-Dateien ? Zu dem Thema lese ich mich zzt. grade erst ein , was Parser und co. angeht, oder reichen auch einfach TextDateien in einem Extra Package ?

 

[MrClave]

Nein, keine XML Dateien.
Properties-Dateien sind einfache Textdateien in besonderer Form.

Dateiname: labelText_de_DE.properties

login=Einloggen
logout=Ausloggen
startText=Herzlich Willkommen blablabla..

Dateiname: labelText_en_UK.properties

login=Login
logout=Logout
startText=Welcome blablabla..

Sowas halt.
Damit umgehst du diese Informationen zu hardcoden.

Google mal nach ResourceBundle und der Properties-Klasse bzw. den Properties-Files.


---


Den vorherigen Post beantworte ich dir später.