Preferences

Status
Nicht offen für weitere Antworten.

dzim

Top Contributor
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
 
Zuletzt bearbeitet:

dzim

Top Contributor
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

Top Contributor
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

Top Contributor
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

Top Contributor
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

Top Contributor
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

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

Wildcard

Top Contributor
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

Top Contributor
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

Top Contributor
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.
 
M

maki

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

Wildcard

Top Contributor
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.
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen


Oben