Objekte als XML

[Sanix]

Hallo,
Ich kann ja ein Objekt serialisieren und danach in eine Datei schreiben. Gibt es auch eine Möglichkeit, dies als XML in eine Datei zu schreiben, so dass es Menschen noch lesen können? Dies wäre ziemlich praktisch zum debuggen teilweise.

 

[SlaterB]

http://www.rz.uni-hohenheim.de/anw/programme/prg/java/tutorials/javainsel4/javainsel_12_013.htm

da steht auch bisschen zu XML, wenn auch vielleicht nur Links,

generell ist vor allem bei untereinander verlinkten Objekten die Abbildung fraglich,
oder hast du eine schöne Baumstruktur ohne Querverweise?

 

[Niki]

import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;

public class XMLSerializer{

	public static void encode(Object o, File f) throws Exception {
		FileOutputStream fos = new FileOutputStream(f);
		XMLEncoder xmlEncoder = new XMLEncoder(fos);
		xmlEncoder.writeObject(o);
		xmlEncoder.close();
	}

	public static Object decode(File f) throws Exception {
		FileInputStream fis = new FileInputStream(f);
		XMLDecoder xmlDecoder = new XMLDecoder(fis);
		Object o = xmlDecoder.readObject();
		xmlDecoder.close();		
		
		return o;
	}
}

 

[Ariol]

XMLDecoder & XMLEncoder sind schon sehr praktisch, aber es funktioniert nicht alles.
Zum Beispiel Listener gehen nicht.

 

[bygones]

XMLDecoder & XMLEncoder sind schon sehr praktisch, aber es funktioniert nicht alles.
Zum Beispiel Listener gehen nicht.

mhm... warum sollte ich listener serializieren ? wuesste nicht, dass sie einen speicherbaren zustand haben ?
oder versteh ich was falsch ?

 

[SlaterB]

sie speichern den Zustand einer GUI, dass sie auf xy reagiert,
das Verhalten als Zustand

so wie man bei einem Button enabled true/ false speichert

 

[bygones]

sie speichern den Zustand einer GUI, dass sie auf xy reagiert,
das Verhalten als Zustand

aber warum sollen sie den Zustand der GUI speichern - das machen die elemente selber.
Fuer mich ist ein Listener etwas, das auf etwas reagiert, etwas daraufhin veranlasst. Sie sind meiner Ansicht nach gedaechtnislos, sie vermitteln nur, daher versteh ich nicht warum man sie seralisieren sollte ?
ich seh nicht das Verhalten als einen Zustand ?!

 

[SlaterB]

sie sind gedächtnislos, aber allein dass sie da sind ist wichtig,
ohne ActionListener ist der Button funktionslos,
irgendwo muss man sich merken, welcher Listener hinzugefügt werden muss,

irgendeine init()-Operation ist die Alternative,
aber das funktioniert auch nicht gerade dynamisch für beliebige Komponenten,
oder Buttons, deren Verhalten sich ändert, die wechselnde Listener haben,

klar kann man alles irgendwo anders speichern, in eigenen Button-Klassen mit zusätzlichen Exemplarvariablen,
die angeben, ob aktuell Listener 1, 2 oder 3 aktiv ist
bzw. es ist nur ein einzelner Listener, der bei jeder Aktion irgendwo nachschaut (nicht in einer eigenen Exemplarvariablen ) ob Aktion 1, 2 oder 3 auszuführen ist,

würde man einfach den ActionListener mitspeichern,
dann könnte man auf natürliche Weise verschiedene Listener unterstützen

würde man dem ActionListner vielleicht gar einen internen Zustand erlauben,
dann könnte man einen ActionListener mit variablen Verhalten persistieren

ob man irgendwas davon will ist fraglich, aber grundsätzlich ist das denkbar

 

[byte]

sie sind gedächtnislos, aber allein dass sie da sind ist wichtig

Naja, aber es muss ja eben nur der Zustand eines Objekts gespeichert werden und nicht das Verhalten des Objekts selbst. Der Listener selbst weiss nicht, zu welchem Objekt er gehört, jedoch weiss ein Objekt, welche Listener er registriert hat. Und diese Information wird ja auch gespeichert.

Ein Button weiss, welche ActionListener er registriert hat. Das wird gespeichert, hat aber sonst nix mit dem Listener zu tun, der zustandslos ist.