AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Minimalistisches PlugIn-System

Ein Thema von DeddyH · begonnen am 24. Aug 2011 · letzter Beitrag vom 25. Aug 2011
Antwort Antwort
Seite 1 von 2  1 2      
ele

Registriert seit: 18. Feb 2009
129 Beiträge
 
Delphi 2010 Professional
 
#1

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 17:29
Klingt ganz vernünftig.

Wenn dein Programm einfach alle DLLs in einem Verzeichnis versucht zu laden, muss man, um ein Plugin zu deaktivieren, das Plugin aus dem Verzeichnis herauskopieren oder umbenennen. Das ist je nach dem etwas umständlich, aber durchaus kein Blocker.

Bei Plugin-Systemen besteht ganz allgemein die Gefahr, dass die Plugin-Schnittstellen nicht genügend durchdacht werden. Das im Nachhinein zu ändern kann u.U. sehr mühsam sein (neu kompilieren aller Dlls), vorallem dann, wenn Dritthersteller anfangen Plugins beizusteuern.

Aus diesem Grund fände ich es wichtig ein System zu haben, dass dir die Version des Plugins (bzw. der Pluginschnittstelle) mitteilt. Dann kannst du notfalls eine Fehlermeldung ausgeben, falls eine Version von einem Plugin dagerkommt, dass dein Programm nicht unterstützt. Ich benutze in diesem Zusammenhang übrigens die Möglichkeit in der Versions-Information des Programmes (oder in diesem Fall DLL) einen neuen Schlüssel zu erstellen (z.B. PluginVersion).
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.666 Beiträge
 
Delphi 12 Athens
 
#2

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 17:35
Sehr guter Einwand. Ich glaube zwar kaum, jemals in den Genuss zu kommen, dass sich ein Dritthersteller für meine Progrämmchen interessiert, trotzdem sollte man so etwas gleich am Anfang mit bedenken.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
ele

Registriert seit: 18. Feb 2009
129 Beiträge
 
Delphi 2010 Professional
 
#3

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 17:37
Der "Dritthersteller" kann manchmal auch ein Alter Ego aus der Vergangenheit sein...
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#4

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 17:46
DLL basierte Plugin Systeme haben immer das Problem, dass man sehr schlecht komplexe Daten (Objekte) austauschen kann. Forms und Frames aus DLLs sind auch immer anfällig für Ärger. Dafür braucht man dann wieder BPLs, gegen die dein Programm und die Plugins gelinkt sind. Auch stellt sich die Frage, wieviel Wissen steckt in den Plugins? Stichwort Menü: hängen die Plugins sich selber da rein, weil sie das Menü übergeben bekommen (nicht gut) oder geben sie bloß eine Liste der Aktionen und die Anwendung hängt sie an. Wie stellt die Anwendung fest, wo sie hinkommen?

DSharp hat übrigens auch einige Units, mit denen man mit wenigen Handgriffen ein Plugin System bauen kann (angelehnt an MEF)
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (24. Aug 2011 um 17:52 Uhr)
  Mit Zitat antworten Zitat
Elvis

Registriert seit: 25. Nov 2005
Ort: München
1.909 Beiträge
 
Delphi 2010 Professional
 
#5

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 06:34
DLL basierte Plugin Systeme haben immer das Problem, dass man sehr schlecht komplexe Daten (Objekte) austauschen kann. Forms und Frames aus DLLs sind auch immer anfällig für Ärger.
Es gibt in Windows einen binär kompatiblen Standard um Objekte auszutauschen: COM. Allerdings stinkt COM und zwar gewaltig.
Das schöne an diesem stinkenden Kadaver ist aber, dass es eben diesen Standard für Objekte hinterlassen hat. Delphis Interfaces implementieren immer IUnknown, die Grundlage aller COM Objekte.
Außerdem ist das Layout von Delphi-Interfaces kompatibel mit allen Sprachen, die IUnknown unterstützen.
Delphis OleVariant ist nur Compiler Magic über IDispatch, welches in der alten COM-Ära für dynamic scripting zuständig war.
Referenzzählung ist auch ein Standard in der COM-Welt, nicht unbedingt erzwungen und autom. wie in Delphi, aber dennoch weiß ein C++-Dev, der ein IUnknown sieht, dass und wie er _AddRef und Release bedienen muss.
Long story short:
Kombiniere klassische DLLs (nicht COM-infizierte Mistviecher!) mit Interfaces, und du bekommst eine Sprach- und Compiler- unabhängige PlugIn-Platform, bei der man nicht mit so grauenvoll plattgedrückten, absolut scheußlichen APIs rumwickeln muss. Damit meine ich die klassische Art, bei der Leute glauben alle exportierten Funktionen dürften nur aus primitiven Typen bestehen...

Die Hostapp würde kaum mehr als einen Service Locator übergeben, und auch einige sinnvolle Services wie Menüverwaltung, Dokumente, etc zur Verfügung stellen. Aber wirklich interessant wird es wenn Plugins selbst Services in den Locator registrieren können.
So dass Plugins von Knut Services von Plugins von Bert nutzen können...

Zitat:
Dafür braucht man dann wieder BPLs
BPLs sind etwas mit dem eigentlich NUR die Delphi-IDE sinnvoll arbeiten kann.
Denn BPLs haben solch komplett inakzeptable Einschränkungen wie: gleicher Compiler, gleiche BPLs, und alles nur Delphi!
Für die IDE mag das okay sein, die kann eh nur mit einer Delphi-Version auf einmal arbeiten und Delphi als erzwungene Voraussetzung tut der IDE auch nicht soo sehr weh. Aber dir selbst willst du solche eine blödsinnige Einschränkung nicht auferlegen.
Das hieße nämlich, dass du niemals wieder auf eine höhere Delphi-Version umsteigen kannst, und deine plugin-schreibenden User auch nicht, da plötzlich alles in sich zusammenstürzen würde. Prost Mahlzeit!

Sorry für die lange Predigt, aber ich halte BPL-Plugins für die digitale Version der jährlichen Grippewelle: Wenn man die Leute nicht regelmäßig impft werden sie doch krank (benutzen BPLs)...

Edit: Man sollte nirgends, in keinem einzigen Binäry, auf (Runtime-)BPLs verweisen.
Hast du auch nur ein einziges von den Viecher in deinem Prozess war's das. Dann kannst du sofort einpacken, was Flexibilität oder niedrigen Blutdruck angeht.
Eine einzige BPL wird als Abhängigkeit mindestens die RTL mitbringen, und ab dem Moment mussu auch die RTL einer ganz speziellen Delphi-Version mitliefern.
Wenn Teile dieser BPL auch nur Teil deiner PlugIn-API sind, kannst du NIE WIEDER auf eine neuere Delphi-Version wechseln ohne alle PlugIns zu töten.
Robert Giesecke
I’m a great believer in “Occam’s Razor,” the principle which says:
“If you say something complicated, I’ll slit your throat.”

Geändert von Elvis (25. Aug 2011 um 06:42 Uhr) Grund: Verdammter Safari und seine hinterhältigen Autokorrekturen... o_O
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 06:43
Ich wüsste echt gerne, wie viele von den selbst gefrickelten Plugin Systemen, die ja ach so flexibel und Delphi unabhängig sind, tatsächlich auch so genutzt werden. In der Theorie ist das alles ganz toll. Aber die konkrete Anforderung zeigt letzlich, ob es tatsächlich externe Plugin Entwickler gibt, die andere Sprachen oder Delphi Versionen einsetzen. Und kommt mir jetzt nicht mit ja, im Firefox oder im Miranda kann ich das...
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Elvis

Registriert seit: 25. Nov 2005
Ort: München
1.909 Beiträge
 
Delphi 2010 Professional
 
#7

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 06:52
Ich wüsste echt gerne, wie viele von den selbst gefrickelten Plugin Systemen, die ja ach so flexibel und Delphi unabhängig sind, tatsächlich auch so genutzt werden. In der Theorie ist das alles ganz toll. Aber die konkrete Anforderung zeigt letzlich, ob es tatsächlich externe Plugin Entwickler gibt, die andere Sprachen oder Delphi Versionen einsetzen. Und kommt mir jetzt nicht mit ja, im Firefox oder im Miranda kann ich das...
Wir benutzen eine Oracle-IDE, die mit Delphi geschrieben ist.
Die nutzt zwar grausige. platte DLLs, aber genau deshalb konnte ich problemlos einige Plugins in C# schreiben.
Der Hersteller benutzt mittlerweile sicherlich nicht mehr Delphi 4 oder 5, mit dem die erste Version rauskam. Und man findet Plugins aus allen möglichen Sprachen für eben dieses Programm.
Nur um dir ein Beispiel zu nennen, welches auch ein Delphi-Host ist.
Robert Giesecke
I’m a great believer in “Occam’s Razor,” the principle which says:
“If you say something complicated, I’ll slit your throat.”
  Mit Zitat antworten Zitat
Benutzerbild von gsh
gsh

Registriert seit: 24. Okt 2004
1.542 Beiträge
 
Delphi XE Architect
 
#8

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 17:49
Ich hab vor langer langer Zeit mal einen Codelib beitrag für ein kleines Plugin System geschrieben, vielleicht bringt dich das auf Ideen:
http://www.delphipraxis.net/73567-fl...ginsystem.html
Die Diskussion dazu ist auch recht interessant:
http://www.delphipraxis.net/74448-fl...iskussion.html
Alex
"Sage nicht alles, was du weißt, aber wisse alles, was du sagst!" Matthias Claudius
"Wer sich über Kritik ärgert, gibt zu, daß er sie verdient hat." Tacitus
  Mit Zitat antworten Zitat
Benutzerbild von mschaefer
mschaefer

Registriert seit: 4. Feb 2003
Ort: Hannover
2.032 Beiträge
 
Delphi 12 Athens
 
#9

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 18:16
Das Problem mit en PlugIn-Systemen ist, dass es meist Insellösungen sind. Um das vom Zeitaufwand in den Griff zu bekommen habe ich dies auch mit eigenständigen Anwendugen gemacht, die nur mit einem versteckten Aufrufparameter starteten. Der Datenaustausch läuft über xml-Files. Es war angedacht es über einen zentraln SOAP-Server zu steuern, aber dazu ist es nie gekommen. Also kurzum, ist ein gangbare Weg aber nicht der Weisheit letzter Schluß.

Grüße
Martin Schaefer
  Mit Zitat antworten Zitat
FredlFesl

Registriert seit: 19. Apr 2011
293 Beiträge
 
Delphi 2009 Enterprise
 
#10

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 19:01
Hi,

Ich habe mal Folgendes gemacht (alles so wie dein Vorschlag, also Verzeichnis durchsuchen, DLL laden usw.):
Jede DLL exportiert neben den Prozeduren "GetName" und "Initialize" (dazu später) beliebige Prozeduren.
Das Einzige, was diese beliebigen Prozeduren gemein haben, ist die Schnittstelle, denn sie sehen alle so aus:

Procedure SomeDLLProcedure (inParam : OleParam, var result, outParam : OleParam);

Ein- und Ausgabeparameter können also Arrays, Streams oder was auch immer sein. Result ist entweder unassigned oder enthält einen Fehler (gestreamed).

Aufgerufen wurden die über einen Plugin-Manager. Nehmen wir an, wir haben eine DLL "MyDLL" und die hat die Prozeduren "Proc1" und "Proc2". Dann rufe ich eine Prozedur der DLL so auf:
ThePluginManager.Call ('MyDLL.Proc1', inParam, result, outParam);

Ich habe damit also eine allgemeine Schnittstelle, die ich beliebig erweitern kann.
Der Plugin-Manager ist auch für die Kommunikation zwischen den DLL verantwortlich, denn er übergibt der DLL per exportierter 'Initialize' Prozedur eine Callback-Schnittstelle, sodaß auch ein Plugin über die gleiche -eben beschriebene Schnittstelle- ein anderes Plugin aufrufen kann. Oder definierte Routinen der Hauptanwendung..

Bei mir gab es in dem Sinne keine Hauptanwendung, denn die DLL implementierten einen Webservice, wobei die einzelnen 'Anwendungen' eben diese DLLs waren.

Desweiteren habe ich dafür gesorgt, das die DLL zur Laufzeit ausgetauscht werden können, ohne die Anwendung (den Service) beenden zu müssen. Die neue oder auszutauschende DLL kann man per TCP direkt in den Service impfen. Der packt die DLL in das Plugin-Verzeichnis, entfernt die alte Version und ab einem definierten Zeitpunkt werden alle Aufrufe an die neue DLL geleitet.

War ziemlich cool und hat auch gar nicht mal so viel Code.
Das Bild hängt schief.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:33 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz