AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Minimalistisches PlugIn-System

Ein Thema von DeddyH · begonnen am 24. Aug 2011 · letzter Beitrag vom 25. Aug 2011
Antwort Antwort
Seite 2 von 4     12 34   
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#11

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 20:37
Zum Design der Schnittstelle kannst du dir mal das angucken: http://www.christian-rehn.de/2011/08...er-api-design/ Fand ich ganz interessant.

mfg

Christian
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
Florian Hämmerle
(Gast)

n/a Beiträge
 
#12

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 21:52
Fand ich ganz interessant.
Der Googletalk breitet sich in der DP langsam aus. Hab ich vorhin auch gerade in nem Thread drauf verwiesen

mfg Florian

BTT: Ansonsten wäre es vielleicht auch ne Möglichkeit, die Schnittstelle über eine der Scriptengines (SE2, PS, etc.) ansprechbar zu machen, dann braucht man nicht extra DLLs zu schreiben, sondern kann zum Produkt einen kleinen Plugin-Editor mitliefern. Vor allem littleDaves SE2 dürfte sich für diesen Zweck anbieten. Aus deiner Hauptanwendung machst du dann einfach bestimmte Objekte für die Scriptengine verwendbar und schon kann man in einem Object Pascal Dialekt eigene Plugins schreiben.
  Mit Zitat antworten Zitat
hanspeter

Registriert seit: 26. Jul 2003
Ort: Leipzig
1.350 Beiträge
 
Delphi XE2 Professional
 
#13

AW: Minimalistisches PlugIn-System

  Alt 24. Aug 2011, 22:45
Mit dll als Plugin kann man früher oder später auch ganz schön auf die Schn... fliegen.
Es verstecken sich 4 größere Problemchen.
1. Ich muss mit BPL arbeiten. Die müssen alle mit der gleichen Compilerversion in der gleichen Umgebung compiliert sein.
Wird (ausversehen) mal eine Init neu compiliert kommt gerne der Fehler ... wurde mit unterschiedlicher Version compiliert- und das erst beim Kunden.
2. Verwechselt jemand völlig gleichnamige BPL in unterschiedlichen Verzeichnissen, dann ist die BPL Hölle los.
3. Der Linker ist garnicht mehr so smart. Liegt auch daran, das im Initialisierungsteil einer Unit Code liegt.
Ich habe mein Programm mal auf einem Delphi-freien Rechner installiert und die von mir als Laufzeit angegebenen BPL dazu.
Danach musste ich noch 76 weitere BPL kopieren, darunter die BDE bis das Programm startfähig war.
4. Delphi registriert bei Windows Klassen über den Klassennamen.
Wird diese Klasse (z.B. Fastreport) in einer weiteren Dll verwendet, dann kommt die Fehlermeldung ...kann nicht geladen werden Klasse bereits registriert.
Der Fehler kommt irgendwann beim Kunden wenn in irgendeiner Konstellation dll A und B geladen werden und bei die gleiche Klasse verwenden wollen.
Die BPL ist so ein alter überflüssiger Zopf und Technologie des vorigen Jahrhunderts.

Um ein Plugin System in Delphi zu realisieren, haben sich bei uns 3 Wege als gangbar erwiesen.
1. Die Installation des Plugin als Comserver.
2. Die Installation des Plugin als Exe und der Verkehr über Aufrufparameter und Exitcode.
Werden mehr Daten benötigt, die Verbindung über ein Memmory mapped File.
Wenn es eine Client-Server Anwendung werden soll, erprobe ich gerade ein weiteres interessantes Verfahren.
Daten werden auf den Server zurückgeschrieben. Ein Trigger reagiert darauf und startet eine Storedprocedure. Diese macht nichts weiter als einen Job auf einen Stack abzulegen.
Dieser Job wird dann von dem Serverprogramm abgearbeitet.

Gruß
Peter
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 07:33
Mit dll als Plugin kann man früher oder später auch ganz schön auf die Schn... fliegen.
Es verstecken sich 4 größere Problemchen.
1. Ich muss mit BPL arbeiten. Die müssen alle mit der gleichen Compilerversion in der gleichen Umgebung compiliert sein.
Wird (ausversehen) mal eine Init neu compiliert kommt gerne der Fehler ... wurde mit unterschiedlicher Version compiliert- und das erst beim Kunden.
2. Verwechselt jemand völlig gleichnamige BPL in unterschiedlichen Verzeichnissen, dann ist die BPL Hölle los.
3. Der Linker ist garnicht mehr so smart. Liegt auch daran, das im Initialisierungsteil einer Unit Code liegt.
Ich habe mein Programm mal auf einem Delphi-freien Rechner installiert und die von mir als Laufzeit angegebenen BPL dazu.
Danach musste ich noch 76 weitere BPL kopieren, darunter die BDE bis das Programm startfähig war.
4. Delphi registriert bei Windows Klassen über den Klassennamen.
Wird diese Klasse (z.B. Fastreport) in einer weiteren Dll verwendet, dann kommt die Fehlermeldung ...kann nicht geladen werden Klasse bereits registriert.
Der Fehler kommt irgendwann beim Kunden wenn in irgendeiner Konstellation dll A und B geladen werden und bei die gleiche Klasse verwenden wollen.
Die BPL ist so ein alter überflüssiger Zopf und Technologie des vorigen Jahrhunderts.
Dem kann ich nicht ganz zustimmen:
zu 1. Entwickelt euer Kunde eigene Plugins? Dann muss er natürlich die korrekten Dateien der BPLs bekommen. Wenn nicht, dann kann der "wurde mit unterschiedlicher..." Fehler nicht kommen. Oder die Anwendung wurde einfach schlampig getestet (auf einem Rechner, der keine Delphi Installation enthält)

zu 2. BPLs im Programm Verzeichnis -> keine Probleme

zu 3. Dann hast du wohl die falschen Runtime packages in deinem Programm angegeben oder in deiner eigenen BPL required. Ich hab selber schon erlebt, dass Leute null Plan von BPLs haben und was in welchen Packages zu finden ist, so dass total unnötige Packages required und demzufolge und ausgeliefert wurden.

zu 4. Genau deshalb benutzt man ja Runtime packages. In dem Fall würde man das Fastreport Package requiren.

Die BPL Technologie mag schon alt sein, deshalb ist sie aber nicht schlecht. Wie bei vielem kann man sich aber viel Ärger einhandeln, wenn man sie nicht zu beherrschen weiß.
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.902 Beiträge
 
Delphi 2010 Professional
 
#15

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 07: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 07: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
3.825 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#16

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 07: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.902 Beiträge
 
Delphi 2010 Professional
 
#17

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 07: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 DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.265 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 08:27
hier ist ja richtig was los. Es ist vielleicht nicht richtig rübergekommen, aber mein Schwerpunkt liegt momentan weniger auf Flexibilität als mehr auf "Easy-to-use". Zu den zu exportierenden Funktionen, wie ich mir das bisher denke:
- "Titel" der Anwendung, ggf. Kurzbeschreibung
- eine Start-Routine
- ggf. Rückmeldung, wenn fertig

Das Hauptprogramm ermittelt also den Titel und fügt z.B. einen Menüpunkt in sein Menü ein. Die Kurzbeschreibung könnte dann für Hints o.ä. verwendet werden. Zusätzlich muss sie sich natürlich merken, welche DLL das war. Wird nun ein Menüpunkt angewählt, wird die DLL geladen, die Start-Routine aufgerufen und auf Rückmeldung gewartet (Message oder so), anschließend wieder entladen und fertig. So ist mein bisheriger Gedankengang.
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
hanspeter

Registriert seit: 26. Jul 2003
Ort: Leipzig
1.350 Beiträge
 
Delphi XE2 Professional
 
#19

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 09:18

Oder die Anwendung wurde einfach schlampig getestet (auf einem Rechner, der keine Delphi Installation enthält)

zu 3. Dann hast du wohl die falschen Runtime packages in deinem Programm angegeben oder in deiner eigenen BPL required. Ich hab selber schon erlebt, dass Leute null Plan von BPLs haben und was in welchen Packages zu finden ist, so dass total unnötige Packages required und demzufolge und ausgeliefert wurden.
Wie bei vielem kann man sich aber viel Ärger einhandeln, wenn man sie nicht zu beherrschen weiß.
Ich möchte mir die Anwürfe und Unterstellungen ausdrücklich verbitten.
Genau wegen der beschriebenen Probleme haben wir die Neuentwicklung in Delphi schon vor längerer Zeit eingestellt.
Aber schön wenn Delphi noch von einigen Fanatikern verteidigt wird.

Peter
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

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

AW: Minimalistisches PlugIn-System

  Alt 25. Aug 2011, 09:48
Wir benutzen eine Oracle-IDE, die mit Delphi geschrieben ist.
Toad? Und ja, wenn man eine kommerzielle Anwendung schreibt, die von Benutzern erweiterbar sein soll, dann stimmt das wohl. Daher sagte ich ja konkrete Anforderung.

Ich möchte mir die Anwürfe und Unterstellungen ausdrücklich verbitten.
Genau wegen der beschriebenen Probleme haben wir die Neuentwicklung in Delphi schon vor längerer Zeit eingestellt.
Aber schön wenn Delphi noch von einigen Fanatikern verteidigt wird.
Ich sprach von meinen Erfahrungen. Soll auch schon einige Delphi Entwickler gegeben haben, die große Anwendungen ohne Probleme mit Runtime Packages entwickelt haben.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (25. Aug 2011 um 09:50 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 +2. Es ist jetzt 17:28 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf