PlugIn-System

[shmia]

Plugins, die eine bestimmte Verarbeitung vornehmen und keine eigene Oberfläche (Formulare) haben funktionieren als ActiveX/COM-Plugin recht gut.
Beispiele:
* Bildmanipulation - das externe Plugin bekommt ein Bitmap und schickt ein verändertes Bitmap (Weichzeichner, ...) zurück.
* Import-Plugin - das Plugin bekommt eine Datei mit best. Format und liefert die Daten aufbereitet zurück

Was überhaupt nicht gut funktioniert sind Plugins die ihre eigenen Formulare mitbringen und als Teil der Anwendung agieren sollen.
Grund: die VCL gibt es dann mehrfach in der Hauptanwendung und im Plugin.
Die beiden Instanzen der VCL kennen sich gegenseitig nicht und das macht Probleme.

Plugins machen nur dann Sinn, wenn es von einer bestimmten Pluginart mehrere Varianten gibt.
Also mehrere Plugins für Bildmanipulation oder Datenimport.

[Luckie]

Eventuell wäre auch ein fertiges Plugin-Framework interessant.

[Bummi]

Ich pflege seit 10 Jahren eine von mir erstellte Anwendung bei der rund 15 Module als DLL nachgeladen werden können (die Kunden des Kunden sollen bekommen was sie bezahlen wollen). Da die Module allen beinhalten was normale Anwendungen auch beinhalten, sich auch im Hauptmenü integrieren, die DLL's mit der Hauptanwendung und untereinander kommunizieren müssen, mußte ich die Erstellung mit Laufzeitpackes wählen. Dies alles ist mit einem selbst erstellen DLL-Template relativ problemlos und und schnell zu implementieren.
Ich würde es heute trotzdem nicht mehr so machen und die Modularität anders umsetzten. Ich klebe mit der Anwendung bis zum Sankt Nimmerleinstag auf Delphi 7 fest, da niemand eine Umstellung aller Einzelmodule auf eine aktuelle Version bezahlen würde. Das heißt auch neue Plugins müssen mit der Uraltverion nachgerüstet werden.

[Tossi]

@Brummi
Ja so ähnlich hatte ich mir das auch gedacht. Die Sache mit den BPL's kenne ich auch. Aber gibt es denn alternativen??
Natürlich wäre es besser wenn die Packages in den Modulen mit drin wären, aber dadurch werden diese riesen gross.

Ohne die Module gäbe es eine Anwendung nur mit einer MainForm. Mehr nicht. Ist ein Adressmdul vorhanden, dann kann ich
eben Adressen verwalten. Natürlich findet die gesamte Be- und Verarbeitung in den Modulen statt, auch visuell(Forms)!!

Thx
Tossi

[plusplus]

I love working with DLL's and I don't understand why there are so many against it. It is robust and flexible. You can plug in C DLL or Delphi DLL. Same with BPL.

Abstract and dynamic loading is the key. Once you know your way around your app can be a plug and play solution that is not only performing well but also fun to maintain.

[plusplus]

@Peter - You are right with BPL's with DLL you don't have that problem you are describing and DLL's work fine even with different compilers.

[shmia]

Vielleicht brauchen wir noch eine Begriffsklärung was ein Plugin überhaupt ist.

Ein Plugin erfüllt eine öffentliche Schnittstelle (bestimmtes Interface oder auch eine Reihe von DLL-Funktionen)
Diese Schnittstelle sollte so designt werden, dass sie sich während der Lebenszeit der Anwendung nicht mehr verändert.

Plugins können in (fast) jeder Programmiersprache erzeugt werden.
Die Hauptanwendung kann Plugins anhand bestimmter Kriterien (z.B. best. Verzeichnis oder Anhand der COM-Kategorie) erkennen und im Prinzip beliebig viele Plugin dynamisch laden.

Ein Anwendungsmodul (so will ich das mal nennen) ist dagegen ein Teilstück einer modularisierten Anwendung.
In .NET entspricht das einem Assembly.
Jedes Anwendungsmodul hat seine eigene Schnittstellen die nicht öffentlich sind.
Während die Anwendung wächst können sich auch die Schnittstellen zu den Anwendungsmodulen verändern.
Anwendungsmodule müssen in der gleichen Entwicklungsumgebung erzeugt werden wie die Hauptanwendung.
Anwendungsmodule haben zwei Vorteile:
* man kann dem Benutzer best. Anwendungsmodule vorenthalten
* bei Bugfixes muss evtl. nur das Anwendungsmodul upgedatet werden

Ansonsten gibt es nur Nachteile für Delphi Programme.

[Tossi]

@Shmia
Ok sorry wenn ich etwas vertauscht habe, aber ich meine letzteres eben Anwendungsmodul.

Genau wie Du es beschrieben hast sollte es bestenfalls laufen. Das Porgramm wächst eben über die Module, die der Kunde dazu kaufen kann. Aber eben die Modulariesierung und eben die Umsetzung in die Listen da hapert es!

Das einlesen der Module aus einem Verzeichnis heraus, kein Problem aber wie komm ich an die Formulare in den Modulen
und wie sprech ich diese dann an.

Thx
Tossi

[Tossi]

hey,
ich dachte mir die Module einfach wie eine Dll mit LoadLibrary laden und bei Erfolg den Zeiger und Name in eine StringList. Nu müsste man die beinhalteten Forms ebenfalls in eine Liste packen. Da hakt es bei mir momentan.


Thx
Tossi

[Bummi]

Für die Forms sind die DLL's zuständig, Du musst exports für die gewünschten Funktionalitäten schreiben.
Du kannst den DLL's ein Callback mitgeben, über den sie die Hauptanwendung mit Informationen für Menüeinträge versorgen kann oder ein von der Hauptanwendung erstelles und wieder hochgereichtes Menuitem mit Leben zu erfüllen.
Der ganze Informationsaustausch lebt von sinnvoll implementieren Callbackfunktionen und exports.