Zitat von
profmaster:
Wie greife ich nun in meiner Anwendung auf mein Plugin zu?
Du musst dazu die IPlugin-Schnittstelle erweitern oder eine andere Schnittstelle aufbauen.
Zitat:
Mich irretiert hier, das neben dem Editoradapter ein TPlugin und noch ein TApp existiert. Nur der EditorAdapter wäre übersichtlicher. Oder ein TPlugin/IPlugin, das alle Zuweisungen und sonstigen Zugriffe abdeckt. Irgendwie verstehe ich das Design noch nicht
Das Design ist hierbei genau andersherum als du es willst. In dem Beispiel besitzt die Anwendung den Editor, und das Plugin greift auf diesen
nur zu.
Zitat:
Warum IPlugin, wo doch der EditorAdapter da ist?
Der EditorAdapter ist nur dazu da, den bereits vorhandenen TSynEdit in ein Interface zu packen. Die alternative wäre eine Klasse von TSynEdit ableiten und die fehlenden Interface-Methode hinzuzufügen. Da aber in dem Beispiel der TSynEdit zur Designzeit auf das Formular gelegt wurde, müsste man dazu erstmal ein
Package schreiben, die Komponente registrieren, ...
Der TEditorAdapter wird in der Anwendung implementiert, weil dort das Editor-Objekt liegt. Das IPlugin wird hingegen im Plugin implemetiert, und die Anwendung greift dann darauf über das vom InitPlugin zurückgelieferte IPlugin zu.
Zitat:
Warum dann noch IApp?
Vielleicht möchte man ja auch noch mehr als nur den Editor ansteuern. Und sowas wie IMenu, IToolBar, IWorkspace, ... passt recht schlecht in ein IEditor hinein (wenn nicht gerade das Programm "Editor" heißt).
Zitat:
Warum nicht nur der EditorAdapter und sonst nichts?
Das wäre dann etwas einseitig. Damit ist es nur möglich in eine Richtung zu kommunizieren. Wie will das Plugin denn auf die Anwendung zugreifen, wenn dafür keine Schnittstelle vorhanden ist. Einfach wild Speicheradressen aufrufen und hoffen, dass dahinter die passende Funktion liegt, wäre wohl in 1 von 2Mrd Versuchen funktionsfähig.
Zitat:
Gibt es Richtlinien zum Interface-Design im Sinne guten Programmierstils?
Guter Programmierstil ist immer das, was man selbst als gut erachtet und was andere auch lesen/verstehen können.
Zitat:
Wie greife ich nun in meiner Anwendung auf dieses Interface zu, ohne allzuviele fehlerträchtige Verrenkungen zu machen.
Dafür gibt es das IPlugin Interface. Es wird vom Plugin implementiert und von allem anderen (der Anwendung) aufgerufen. Genauso läuft es mit IApp ab. Es wird von der Anwendung implementiert und von allem anderen (dem Plugin) aufgerufen.
Zitat:
Im Beispiel ist mir die Methode TForm1.mCfgToolsClick(Sender: TObject); zu unübersichtlich.
Da stimme ich dir zu. Der OnClick-Handler ist nicht wirklich übersichtlich. Normalesweise lädt man die Plugins beim Start der Anwendung (oder On-Demand, aber dann auch etwas schöner).
Also die Plugins laden und die exportierte Funktion InitPlugin aufrufen. Das von dieser zurückgelieferte IPlugin Interface in eine TIinterfaceList (oder eine davon angeleitete, spezialisierte TPluginList) schieben. Und jetzt die Plugin-
DLL auf keinen Fall freigeben, denn sonst hängen die Interfaces in der Luft.
Im OnClick-Handler muss man jetzt nur noch durch die PluginList iterieren und das passende finden. Das Suchen des passenden Interfaces lässt sich auch noch in eine eigene Funktion auslagern, die entweder das IPlugin oder nil zurückliefet (ggf. bei nil eine
Exception auslöst).
Im OnDestroy dann einfach PluginList.Clear aufrufen und die DLLs entladen (oder das von Windows machen lassen).