Optionensysteme schreiben

[Arbon]

Hallo.

Ich würde gerne wissen wie man ein gutes Optionensystem schreibt. Gibt es dazu irgendwo Anleitungen?
Ich würde es grundsätzlich so machen:
Die Speicherung der Optionen würde ich zB einfach nach einem bestimmten Schema in eine Datei schreiben und wieder lesen (von Sachen wie Registry halte ich eigendlich nichts. Beeinträchtigt die Portabilität). Dazu kann man grundsätzlich einfach die Properties Klasse von java benutzen.
Zum Zugriff auf die Daten wäre zB eine Singleton Klasse nützlich, über welche man sich Optionen über den jewiligen Schlüssel holen kann. Allerdings weiss ich nicht ob dies so optimal ist.
Und zum Ändern der Optionen würde man eben einen Dialog schreiben, mit Checkboxen, Textfeldern und ähnlichem. Allerdings gestaltet sich das bei zunehmender Anzahl an Optionen ziemlich komplex, falls es Abhänigkeiten zwischen den Optionen o.ä. gibt. Die sofortige Aktualisierung der Optionen bzw. bei Drück auf den Übernehmen button gestaltet sich ebenfalls als schwierig. Hier wäre vl ein Listener oder ein Observer nützlich.

Ich denke allerdings dass mein Ansatz alles andere als gut ist. Deswegen würde ich gerne wissen was ihr davon haltet bzw. wie man das besser angehen könnte. Wie gesagt das System sollte auch bei vielen Optionen nicht allzu komplex oder schmutzig werden.

mfg

 

[Atze]

ich würde es statt mit dem simplen "in eine datei schreiben" mit serialierung von objekten versuchen. ist zwar from prinzip das gleiche, also der zustand eines objektes wird in eine datei geschrieben, aber du hast dann durch die deserialisrung leichteren zugriff auf die objekte.

 

[diggaa1984]

hi,

also ich bin gerade dabei die Settings für ein Syntaxhighlighting im Editor zu speichern. Das ganze soll natürlich nach Neustart des Programmes auch wieder hergestellt werden können.

Erster Ansatz war dabei die Propertie-Klasse zu nutzen und das ganze als *.properties abzulegen. Allerdings sehe ich keine Notwendigkeit dieser expliziten Datei im user-ordner. Als weitere Alternative les ich immer öfter "Preferences" .. dort können ebenfalls Eigenschaften abgelegt werden, wobei dir als Programmierer die Frage "wie mach ich es persitent" abgenommen wird. Die interne Datenhaltung wird nicht explizit in der Api dieser Klasse erklärt, aber das brauchst du auch gar nicht um damit zu arbeiten.
Du kannst Eigenschaften definieren welche zB von jeder klasse in einem bestimmten package greifbar sind.

Ich bin auch gerade dabei diese Ansatz zu nutzen und find ihn auch recht handlich. Man kann dabei auch unterscheiden zwischen user-eigenschaften oder system-eigenschaften.

Kannst dir ja mal anschaun: Preferences

Serialisierung sollte man nicht dazu nutzen, zumal hier wesentlich mehr Infos abgelegt werden als überhaupt nötig. Ausserdem hast du dann Probleme, wenn du die Klasse einmal änderst. Im schlimmsten Fall lässt sich die serialisierte Datei nicht mehr laden.

 

[eRaaaa]

Die interne Datenhaltung wird nicht explizit in der Api dieser Klasse erklärt, aber das brauchst du auch gar nicht um damit zu arbeiten.

Where is the Preferences Data Really Stored?

The actual storage of preferences information is implementation dependent. We programmers don't need to know where the data is stored, as long as the Preferences API always works the same on all platforms, which it does. The important thing to know is that the data really is stored persistently somewhere.

Nevertheless, the curious might want to know where the data is really stored. In practice, the Sun J2SE implementation on Windows platforms utilizes the Windows Registry as can be verified by examining the registry.

On Solaris and Linux, the user node is normally stored in a hidden file in the user's home directory. Other implementations might use directory servers or SQL databases. It really is implementation dependent. And it really is unimportant.

interessant ^^

 

[diggaa1984]

man kann sichs ja fast denken, aber steht nich in der API

 

[sliwalker]

Also beide Ideen haben was. Es fehlt nur leider die wichtigeste Informationen.
Was für Optionen brauchst Du? Brauchst Du wahlfreien Zugriff oder musst Du ein Objekt einlesen/erzeugen um es im Programm zu verwenden. Laufzeitverhalten? Schlüssel->Wert-Paare? String reicht Dir als Wert? Oder musst Du vielleicht ByteArrays speichern?

Du siehst, beide Ideen haben ihren Sinn. Die Frage ist was Du brauchst.

 

[tuxedo]

Naja, der UserPreferenceStore eignet sich hier doch bestens... Man kann sogut wie alles drin speichern, hat eine schicke "Properties"-like Schnittstelle und das ganze ist noch Platform-Unabhängig.

Wozu also das Rad neu erfinden?

- Alex