RCP Code Organisation wegen reuse

[mandypb86]

Hallo zusammen,

nachdem ich nun eine Weile mit RCP gearbeitet hab und auch schon so einige Hürden gemeistert hab, geht es nun an ein "richtiges" Projekt. Da ich jetzt noch nicht vorhersagen kann, ob das Programm mal erweitert werden soll und ob es evtl. auf mobilen Geräten laufen soll, möchte ich meinen Code möglichst flexibel halten.

Ich besitze das Buch "Eclipse Rich Client Platform" von McAffer/Lemieux/Aniszczyk. Dort wird in einem Kapitel ein Ansatz vorgestellt, der alle Teile in eigene Plugins aufteilt. Soll heißen:

• core Plugin (nur Model und Logic)
• UI Plugin (nur JFace OHNE Workbench)
• UI.Workbench Plugin (alle Workbench-abhängigen Sachen)
• Product Plugins, die die eigentliche RCP Application enthalten, sowie Perspectives, ActionBarAdvisor u.Ä.

Desweiteren:

• für jede Product Configuration ein eigenes Feature

Ich halte das Konzept für sehr sinnvoll, hab aber keine konkrete Idee, wo ich da anfangen soll (abgesehen vom Model natürlich) und was ich beachten muss, damit das auch funktioniert.

Wie muss ich wo welche Plugins einbinden?
Was muss ich evtl. wo exportieren?
Was muss ich speziell beachten, wenn ich Adapter benutzen will? (Dieser Artikel ist super, aber da muss das Plugin, worin ich den Adapter programmiere, die Model-Klasse kennen, deshalb hat mich das verwirrt. Jemand Tipps?)

Schonmal danke für jegliche Hinweise und Vorschläge, wie ich das am Besten realisieren kann.

Gruß
Mandy

 

[Wildcard]

Wie muss ich wo welche Plugins einbinden?

Verstehe die Frage nicht

Was muss ich evtl. wo exportieren?

Du musst natürlich in jedem Bundle die Packages exportieren die nach aussen sichtbar sein sollen.

Was muss ich speziell beachten, wenn ich Adapter benutzen will?

Hmm, nix? Du musst halt wissen wie die Sache funktioniert und wie man eine Adapter Factory erstellt. Steht doch aber sowieso alles in dem Artikel

 

[mandypb86]

Wie muss ich wo welche Plugins einbinden?

Verstehe die Frage nicht

Hehe, ok, ich versuchs nochmal, wobei ich da mittlerweile selber ein bisschen drüber nachgedacht hab (soll ja helfen *g*).

Die Plugins müssen sich ja untereinander kennen, nehme ich mal an, Stichwort Dependencies dürfte wohl das sein, was ich meinte und was ich auch so gelöst hab.

Wie weit geht so eine Dependency? Kann man das mit Vererbung vergleichen oder muss ich jede Dependency extra angeben? Also gibt es eine Hierarchie im Sinne von

Product Plugin -> Workbench -> UI -> Core

und das Product Plugin kennt dann auch das Core Plugin oder ist es eher eine Baum-ähnliche Geschichte?

Product -> (Workbench, UI, Core)
Workbench -> (UI, Core)
UI -> Core

"->" soll hier "Dependencies" abbilden

Du musst natürlich in jedem Bundle die Packages exportieren die nach aussen sichtbar sein sollen.

Also alle Packages aus dem Core-Plugin, auf die ich aus einem anderen z.B. UI Plugin, zugreifen will, müssen in dem Tab "Exported Packages" des Core Plugins auftauchen, korrekt?

Was mich jetzt grad zu der Frage führt: Hängen Dependencies und Exported Packages zusammen?

Sprich: wenn ich die Model-Objekte aus dem Core-Plugin in dem UI Plugin nutzen will, muss ich sie dann sowohl im Core-Plugin exportieren, als auch im UI Plugin das Core-Plugin als Dependency angeben? Oder reicht es sie zu exportieren?

Hoffe, nicht wieder un-/missverständlich und danke für die Hinweise.

Mit den Adaptern guck ich nochmal in Ruhe.

Gruß
Mandy

 

[Wildcard]

Du brauchst grob gesagt die Dependencies, die du eben brauchst.

Product Plugin -> Workbench -> UI -> Core

Mit Product Plugin meinst du das Plugin dass das Eclipse Product definiert? Typischerweise hat das nicht viel funktionalität und daher auch kaum dependencies.
Ansonsten, ja, du gehst von oben nach unten mit den Abhängigkeiten (wenn du es in logischen Schichten betrachtest).

Sprich: wenn ich die Model-Objekte aus dem Core-Plugin in dem UI Plugin nutzen will, muss ich sie dann sowohl im Core-Plugin exportieren, als auch im UI Plugin das Core-Plugin als Dependency angeben?

Richtig. Es gibt zwei Arten eine Abhängigkeit zu definieren:
1. require bundle - du beziehst dich auf ein bestimmtes Bundle und siehst alles was dieses Bundle exportiert
2. import package - dir ist egal welches Bundle die Funktionalität bereitstellt

Import Package ist flexibler als require bundle, allerdings wird im Eclipse umfeld traditionell eher require bundle verwendet

 

[trabiator601]

Hallo liebe Gemeinschaft,

ich klinke mich hier mit ein, da ich konzeptionell vor dem selben Problem stehe.

Wie Mandy habe ich ein GUI-Plugin, Core-Plugin, Libs-Plugin und DB-Plugin.
Nun überlege ich, welches Plugin den Einstieg in die Anwendung darstellt und welche Plugins über ExtensionPoints angemeldet werden.

Unstrittig scheint mir, dass ein DB-Plugin über einen ExtensionPoint an Core angemeldet wird. Mir stellt sich nur die Frage, wie ich dann sauber mögliche Konfigurationseinstellungen aus dem DB-Plugin an die GUI weiterleite, um Einstellungen wie Benutzername und Passwort oder lokalen Pfad über die GUI zu setzen können. Diese Preferences könnten ja je nach DB Typ unterschiedlich sein.

Aber wie sollte ich den Rest gliedern? Für mich ist das auch etwas das Henne-Ei-Problem.

Variante 1:
Das Core-Plugin mit dem Datenmodell und der Servicedefinition könnte der Ausgangspunkt sein.
Ich definiere einen ExtensionPoint Frontend.
Das Frontend könnte dann ein GUI-Plugin oder WebService-Plugin sein.
In der Produktkonfiguration wird dann zunächst Core gestartet und das lädt die restlichen Plugins nach.

Variante 2:
Die RCP Anwendung ist ja schlußendlich als graphische Anwendung gedacht. Also starte ich das GUI-Plugin. Das sucht sich dann über einen ExtensionPoint das zugehörige Core-Plugin, aktiviert es und startet somit den Service der sich um die Datenhaltung kümmert.

Was sagt ihr dazu?

Danke Steffen

 

[Wildcard]

Du startest nur die Application, alles andere wird schon in der richtigen Reihenfolge gestartet und geladen, darum kümmert sich OSGi.
Konfigurationen steuert man sinnvollerweise über die Preferences bzgw. SecurePreferences API