RCP RCP Einstellungen

[BlauerBall]

Guten Tag Leute

Ich spiele gerade ein bisschen mit Eclipse RCP rum und bin gerade etwas verwirrt werden Einstellungen bzw. Preferences. Ich hab mir schon das Tutorial von Eclipse Preferences - Tutorial durchgelesen.

Was ich gerade mache ist folgendes:
Ich hab ein RCP-Plugin welches eine Oberfläche besitzt und eine PreferencePage. Die Einstellungen sollen aber in einem anderen Plugin names "Core" gespeichert werden. Die klappt auch alles soweit wunderbar.
Hier mal der Code für die PreferencePage um den PreferenceStore des Core-Plugin zu verwenden.

@Override
	public void init(IWorkbench workbench) {
		setPreferenceStore(CoreActivator.getDefault().getPreferenceStore());
	}

Im Core-Plugin hab ich einen PreferenceInitializer erstellt und hier fängt meine Verwirrung an. Was ist der richtige Weg um den Preference Store zu erstellen und mit Standardwerten zu füllen?

Ist es:

IEclipsePreferences node = DefaultScope.INSTANCE.getNode(CoreActivator.PLUGIN_ID);
node.putBoolean("TEST", false);

oder ist es:

IPreferenceStore store = CoreActivator.getDefault().getPreferenceStore();
store.setDefault("MySTRING1", "http://www.vogella.com");

Welches ist die richtige Lösung? Wie gesagt sie funktioniert soweit, nur ich finde sie irgendwie unschön.

Nachteilig ist auch, das ich im Core-Plugin das Paket mit dem CoreActivator exportieren muss, damit ich auf den CoreActivator im RCP-Plugin zugreifen kann. Geht das nicht auch noch anders?!

MFG
Blauerball

 

[Gonzo17]

Die erste Lösung kannte ich bisher garnicht, dementsprechend bin ich immer den zweiten Weg gegangen. Was genau findest du daran unschön?

Nachteilig ist auch, das ich im Core-Plugin das Paket mit dem CoreActivator exportieren muss, damit ich auf den CoreActivator im RCP-Plugin zugreifen kann. Geht das nicht auch noch anders?!

Nein, das geht wohl nicht anders. Du möchtest ja mit anderen Plugins auf dieses Core-Plugin zugreifen, um eben zum Beispiel die Preferences auslesen zu können. Dementsprechend muss die Klasse ja auch nach außen hin sichtbar sein.

 

[BlauerBall]

Hi

Entschuldigung für die späte Antwort, hatte viel zu tun.
Ich finde es deswegen "unschön" weil die Komplette Activator-Klasse nach außen hin sichtbar gemacht wird. Diese Klasse kümmert sich ja um den Lebenszyklus des Plugins. Ich denke mal schöner wäre es mit einem Interface, welches nach außen hin sichtbar ist und per Interface dann irgendwie auf das Core-Plugin zugegriffen wird.

 

[Gonzo17]

Das kannst du natürlich so machen. Hab es eben getestet. Ein Interface definieren, das deine zusätzlichen Methoden definiert, das in ein neues Package legen, dazu eine Factory-(oder sonstwas-)Klasse die dir eine Instanz von diesem Interface liefert und da gibst du dann einfach deinen Activator zurück, der dieses Interface implementiert.
Nachteil ist natürlich, dass du auf die eigenen Methoden der Activator-Klasse nicht zugreifen kannst, nur auf die, die durch das Interface dazugekommen sind. Wobei du das ja eventuell explizit verhindern möchtest.
Musst aber bedenken, dass immer Packages nach außen hin freigegeben werden, also natürlich dann das Interface in ein anderes Package legen als den Activator.

 

[BlauerBall]

Hi

Könntest du das mit dem Interface mal genauer erklären? Steh grad irgendwie auf dem Schlauch^^ Hab es jetzt mit einer Factory-Klasse in einem öffentlichen Package gelöst, aber das mit dem Interface da steh ich grad auf dem Schlauch^^

Ich bin sowieso grad noch verwirrter als vorher. Da ich zwar meine Einstellungen mit der Anweisung:

IEclipsePreferences preferences = DefaultScope.INSTANCE.getNode(Activator.PLUGIN_ID);
		preferences.putBoolean("TEST", false);
		preferences.put("TEST2", "ISCH BIN EIN VALUE");

initialisieren kann. Ich kann sie aber nur mit der Anweisung:

IPreferenceStore store = Preferences.getStore();
		String test2 = store.getString("TEST2");

erfolgreich auslesen. Mit dieser Anweisung

Preferences prefs = InstanceScope.INSTANCE.getNode(Preferences.getPluginId());
		String test = prefs.get("TEST2", "Hat nicht geklappt");

hingegen nicht.

Was mach ich hier falsch?!

 

[Gonzo17]

Also wie gesagt, ich arbeite ausschließlich mit IPreferenceStore, deswegen kann ich dir zu IEclipsePreferences nichts sagen. Aber ich konnte eigentlich immer alles damit machen, was ich so machen wollte.

Zu der Sache mit dem Interface. Angenommen deine Activator-Klasse liegt im Package

example

, dann machst du ein neues Package

example.blub

und erstellst dort das Interface

MyActivator

und die Klasse

ActivatorFactory

. Die Namen sind jetzt einfach mal hingesaut, kannst du auch anders nennen. Jetzt implementierst du das Interface

MyActivator

bei deiner Activator-Klasse. Im Interface stehen dann zB Methoden, die dir die Preferences liefern oder über die du Preferences setzen kannst. In der

ActivatorFactory

schreibst du zB ne statische Methode

getActivator()

die dir ein Objekt liefert, das

MyActivator

implementiert hat - das wird in deinem Fall eben genau deine Activator-Klasse sein, deswegen wird die Methode wohl einfach ein

return Activator.getDefault();

haben oder sowas. Letztlich jetzt noch in deiner plugin.xml das Package

example.blub

sichtbar machen. Damit kannst du von einem anderen Plugin aus die Klasse

ActivatorFactory

mit der Methode

getActivator()

aufrufen ohne den Activator selbst bekannt machen zu müssen und somit kann man auch nur das mit dem Activator tun, was durch das Interface vorgegeben ist.

 

[BlauerBall]

Danke fürs Erklären, hab ich dann doch nicht so falsch verstanden wie ich dachte trotzdem danke!!

Das mit den "IEclipsePreferences" werd ich auch mal sein lassen und weiterhin den "IPreferenceStore" verwenden.

 

[Gonzo17]

Danke fürs Erklären, hab ich dann doch nicht so falsch verstanden wie ich dachte trotzdem danke!!

Das mit den "IEclipsePreferences" werd ich auch mal sein lassen und weiterhin den "IPreferenceStore" verwenden.

Gerne, kein Problem.
Wichtig ist dass du dir klar machst, was du denn möchtest. Wenn du, wie du sagst, nicht möchtest, dass man den CoreActivator von außen direkt sehen kann, dann wäre das eine mögliche Lösung, evtl gibts da aber noch elegantere Varianten. Du könntest natürlich auch folgenden Ansatz fahren. Du legst alle möglichen Einstellungsmöglichkeite in eine eigene Klasse, zB

Settings

(oder whatever). Diese Klasse machst du nach außen hin sichtbar, den CoreActivator nicht. Intern greifst du in der Settings-Klasse dann auf den Activator zu. Damit hast du tatsächlich den CoreActivator zu keinem Zeitpunkt nach außen gegeben, auch nicht über ein Interface. Und du kannst ja mehrere Klassen machen, die sich um verschiedene Dinge kümmern, nicht nur Settings, sondern auch ImageManager, RessourceManager, usw und sofort.