# Preferences



## dzim (24. Nov 2009)

Hi zusammen,

wie man PreferencePages erstellt (ob mit oder ohne FieldEditorPreferencePage) ist mir so weit klar (das ist auch nicht sonderlich schwer, wenn man sich den Extension Point dazu anschaut).

Die Frage ist aber: Wie und wo genau speichert man die Preferences?

Lars Vogel beschreibt in seinem Tutorial Eclipse Preferences - Tutorial, dass man die drei verschiedenen Scopes verwenden kann, nutzt sie in dem oberen Beispiel (oder wenigstens einen davon) in seiner FieldEditorPreferencePage aber nicht.

Ich würde daher nur gern wissen wollen
a) auf welchen Scope arbeitet der PreferenceStore meines AbstractUIPlugins
b) reicht es, einfach in diesen zu schreiben, wenn ich den Configuration Scope (also den "persistenten" Scope verwenden will?

Vielen Dank vorab (wie immer!)
Daniel


----------



## dzim (24. Nov 2009)

Noch eine Frage hinterher...

Ich will etwas artähnliches für meine Anwendung bauen, wie Eclipse:
Beim Start öffnet sich ein Dialog (im SplashHandler), der eine Art Workspace Directory abfragt (das soll unter anderem gespeichert werden).
Jetzt wähle ich einen Ordner und bekomme einen String. Den speicher ich in den Preferences (wenn ich die Fragen von oben geklärt habe).
Aber: Wie verwende ich das dann am besten? Als File, IPath, IRessource, IWorkspace.......

Ich hoffe ihr versteht ungefähr, worauf ich hinaus will!


----------



## dzim (24. Nov 2009)

Noch eine Frage: Benötige ich den Extension Point "org.eclipse.core.runtime.preferences" um meine Preferences initial zu befüllen? Oder genügt es, "einfach" in sie hinein zu schreiben?


----------



## Wildcard (24. Nov 2009)

Preferences sind fire and forget. Das Framework kümmert sich um initialisierung und persistierung. Die Scope regeln die Sichtbarkeit und ergeben sich quasi automatisch.
Installation: Eclipse weit
Instance: Workspace weit
Project: na was wohl 



> Aber: Wie verwende ich das dann am besten? Als File, IPath, IRessource, IWorkspace.......


Das habe ich nicht ganz verstanden


----------



## dzim (25. Nov 2009)

Ach ich denke, das ist auch erst mal nicht so wichtig. 
Das war eher eine Design-Frage, die ich mir auch hätte verkneifen können, da ich eh nicht auf der Basis von Projekten (also nicht im Sinne des ProjectExplorers etc.) arbeite.

Danke trotzdem  Ich werde es dann also wohl mit Installation oder Instance Scope abdecken.

Ich hab damit ein wenig herum gespielt und nutze jetzt erst einmal die Variante über Plugin.getDefault().getPreferenceStore() - kA, was das für ein Scope ist (vermutlich mindestens Instance) - und es geht erst einmal.


----------



## Wildcard (25. Nov 2009)

Ja, das ist Instance. Leider wurde die API einige male überarbeitet und jetzt gibt es mindestens 3 Preferences Konzepte. Die Scope Variante (Preferences Klasse) ist die aktuelle, die alten sind darauf umgebogen.


----------



## dzim (26. Nov 2009)

*lol*
ganz toll - mal sehen was man sich dann bei e4 so einfallen lässt um uns wieder ein bisschen zu verwirren ;-)


----------



## Wildcard (26. Nov 2009)

Sehr viel. Allem vorran Dependency Injection, das Toolkit Modell und JavaScript basierte PlugIns.
Bei e4 wird sich alles um EMF drehen. Wer EMF noch nicht kennt, jetzt wird es Zeit zum einarbeiten


----------



## dzim (30. Nov 2009)

Nicht zu vergessen: CSS-Branding (was ich, um es mal mit den Worten meiner Generation auszudrücken, als ein sehr cooles Feature ansehe...)

Ach so ein Mist, ich seh mich echt unter Zeitdruck geraten! (@EMF) Zu meinem Glück sollen ja "alte" Plugins auch weiterhin unterstützt werden - jedenfalls vorerst.

BTW: DI bei e4 - wie wird das laufen? Doch nur über die "klassische" Konstrucktor-Variante, oder? (Gut ich denke man kann da immer Spring oder Guice drauf setzen, aber trotzdem...)

Na mal sehen, wie das wird!


----------



## Wildcard (30. Nov 2009)

dzim hat gesagt.:


> BTW: DI bei e4 - wie wird das laufen? Doch nur über die "klassische" Konstrucktor-Variante, oder? (Gut ich denke man kann da immer Spring oder Guice drauf setzen, aber trotzdem...)


Weiß ich leider auch noch nicht. Ich würde aber behaupten das sie sich für die standartisierte Variante entscheiden mit Eclipse eigener Modulkonfiguration.


----------



## dzim (1. Dez 2009)

Hm... Na dann lassen wir uns einfach mal überraschen!


----------



## maki (1. Dez 2009)

Soweit ich weiss stellt Spring mit SpringDM die Referenzimplementierung für die OSGi 4.2 Dependency Injection.


----------



## Wildcard (1. Dez 2009)

Die e4 Jungs haben auf dem Eclipse Summit Europe erwähnt das sie im Zuge der e4 Entwicklung eine eigene Implementierung des Standards entwickelt haben. Ob es dabei bleibt, oder später eine andere Implementierung verwendet wird wurde nicht erwähnt.


----------



## dzim (2. Dez 2009)

Hm, na dass musst du ja am besten wissen, da du ja dort warst...


----------

