Minimalistisches PlugIn-System

[Iwo Asnet]

Zitat von DeddyH:

..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

Sowas haben wir auch: Ein Diagnosesystem für Maschinen. Das Plugin-System ist quasi eine Toolbox für unterschiedliche Diagnoseroutinen. Wenn der Techniker (Null Ahnung von Programmierung) irgendwo auf der Welt unterwegs ist und eine 'Spezialdiagnose' braucht, dann kann sich ein Programmierer hier kurz hinsetzen, schreibt die Diagnose als Plugin und schickt ihm die DLL. Der schmeisst sie ins Plugin-Verzeichnis, registriert die DLL und fertig. Wenn die DLL sich als praktisch erweist, kommt sie ins Standardportfolio.

Wir haben neben dem Namen und einer Kurzbeschreibung auch die Versionsnummer des Plugins mit aufgenommen.

Die Parametrierung des Plugins erfolgt über ein einfachen String der Form "Param1='1';Param2='xyz'". Dafür existiert der blöde TValueListEditor, der sonst zu nix zu gebrauchen ist. Wir wollten noch einen schicken tollen Parametereditor bauen, aber dafür müssten wir vom Plugin den Datentyp jedes Parameters wissen... Bisher hatte keiner Bock, das aufzubohren.

Es ist eine Anwendung, die an Spimplizität kaum zu über/unterbieten ist. Aber als Plugin-Framework ist es gut genug.

[neo4a]

Zitat von hanspeter:

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.

Hallo Peter,

Dein Post-Counter zeigt, dass Du lange und aktiv hier im Forum unterwegs bist. Ein Wechsel der Entwicklungsumgebung weg von Delphi ist für mich nachvollziehbar.

Wie kommt es aber, dass aus einem aktiven Delphi-Entwickler und einem, der noch jetzt aktiv in einem Delphi-Forum unterwegs ist, einer wird, der seinen Mitstreitern bei Delphi-Lösungen Fanatismus vorwirft?

Wenn es nur eine ungeschickte Wortwahl ist, okay - aber ansonsten finde ich Deine Attitüde ("Ihr Armleuchter - ich weiß es besser, sage aber nicht was") befremdlich, um es einmal höflich zu formulieren.

[ehX]

Ich verwende ein PlugIn-System meist so, wie es viele Spiele machen: keine DLL's, die nativen Code beinhalten, sondern das Hauptprogramm stellt alle für das PlugIn-System verfügbaren Funktionen als Lua-API zur Verüfgung, auf die man dann Scripten kann.
Die Plugins selbst bestehen dann aus einer oder mehreren lua-Dateien (oder compilierte luac-files) und haben zusätzlich eine TOC-File mit z.b. Versions-Informationen, welche Dateien zusammengehören, API-Version usw. Insgesamt so ähnlich wie z.B. das Addon-System von WoW.

Für mich war das ein gangbarer Weg für ein Plugin-System, da man so die volle Kontrolle vom Host hat, was ein Plugin darf und was nicht (keine Dlls, die geladen werden) Der Nachteil dabei ist natürlich, dass die interne API alle möglichen Dinge abdecken muss wie z.B. neue GUI-Elemente über die Lua-API dynamisch erstellen, binden etc. Das macht das Ganze natürlich aufwändiger.
Die Host-Anwendungen sind bei mir dann auch meistens in vollständiger Modul-Bauweise gebaut und werden über ein "Core-Plugin" verbunden.
So ist man auch flexibel, die Reihenfolge beim Start der eigenen Anwendung vollständig selbst festzulegen, welche Fenster geöffnet werden, was initialisiert wird etc. und alles über das Core-Plugin zu ändern.
(dazu muss natürlich die API jegliche GUI-create-Funktionen, Initialisierungs-Routinen der Module, Berechungsfunktionen o.Ä. nach aussen porten und braucht zumindest eine kleine Schicht, die das Window-Management übernimmt)

Ich weiss nicht, ob so ein Ansatz für dich in Frage käme, ich bin damit bis jetzt eigentlich immer ganz gut gefahren.

[Florian Hämmerle]

Zitat von ehX:

Ich verwende ein PlugIn-System meist so, wie es viele Spiele machen: keine DLL's, die nativen Code beinhalten, sondern das Hauptprogramm stellt alle für das PlugIn-System verfügbaren Funktionen als Lua-API zur Verüfgung, auf das man dann Scripten kann.
Die Plugins selbst bestehen dann aus einer oder mehreren lua-Dateien (oder compilierte luac-files) und haben zusätzlich eine TOC-File mit versions-Informationen, welche Dateien zusammengehören etc. So ähnlich wie das Addon-System von WoW.

Für mich war das ein gangbarer Weg für ein Plugin-System, da man so die volle Kontrolle vom Host hat, was ein Plugin darf und was nicht (keine Dlls, die geladen werden) Der Nachteil dabei ist natürlich, dass die interne API alle möglichen Dinge abdecken muss wie z.B. neue GUI-Elemente über die Lua-API dynamisch erstellen, binden etc. Das macht das Ganze natürlich aufwändiger.
Die Host-Anwendungen sind bei mir dann auch meistens in vollständiger Modul-Bauweise gebaut und werden über ein "Core-Plugin" verbunden.
So ist man auch flexibel, die Reihenfolge beim Start der eigenen Anwendung vollständig selbst festzulegen und über das Core-Plugin zu ändern.
(dazu muss natürlich die API jegliche GUI-create-Funktionen, Initialisierungs-Routinen der Module o.Ä. nach aussen porten)

Was auch meinen früheren Vorschlag der Verwendung von littleDaves ScriptEngine wieder ins Gespräch bringt =D

[ehX]

Zitat:

Was auch meinen früheren Vorschlag der Verwendung von littleDaves ScriptEngine wieder ins Gespräch bringt =D

Jau, die ScriptEngine ist schon eine coole Sache!
Ich persönlich bin halt ein Lua-Fan, deswegen verwende ich das....auch wenn sich die ScriptEngine wohl für ein Delphi-Projekt insgesamt mehr anbietet..

[DeddyH]

Vielleicht sollte ich doch einmal erklären, wozu das Ganze eigentlich gut sein soll: meine Frau ist Lehrerin an einer hiesigen Förderschule und betreut dort die Werkstufe (die 16- bis 21-jährigen). Die Schüler dieses Alters lernen hauptsächlich, im täglichen Leben möglichst ohne fremde Hilfe zurecht zu kommen. Nun habe ich mir gedacht, ich könnte ein kleines Programm schreiben, das sich auf einfache Weise beliebig erweitern lässt. So könnte es z.B. Mini-Spiele und Mathe-Übungen anbieten (Wechselgeld zählen und solche Dinge). Man könnte natürlich auch viele kleine Exen erstellen und die dann einfach starten, ich möchte aber verhindern können, dass der Schüler Hans über den Explorer immer "Fang den Ball" startet, sondern nach 3 mal auch wieder etwas "Gescheites" machen muss. So kam ich auf die DLL-Idee. COM und *.bpl-Geschichten mögen ja durchaus ihre Berechtigung haben, sind mir für dieses Vorhaben aber viel zu oversized.

[BUG]

Wenn es nur darum geht, dann könntest du das schnell das mit einer "Seriennummer" lösen, das einfach als Parameter übergeben wird.

zB. in der Form (salt + hash(salt + geheimnis + systemzeitInMinuten))
Im aufgerufenen Programm prüft du, ob das Passwort für diese oder die letzte Minute gültig war.

Besonders sicher ist es zwar nicht, aber einfach zu implementieren.


Interessant wäre aber auch, wenn man die "Startberechtigung" bei einem zentralen Server abruft. Von dort aus könnte man dann leicht Berechtigungen verteilen.

[neo4a]

Zitat von ehX:

Ich persönlich bin halt ein Lua-Fan, deswegen verwende ich das

Kannst Du dazu vielleicht ein simples Beispiel posten?

[ehX]

Zitat:

Kannst Du dazu vielleicht ein simples Beispiel posten?

Von was jetzt genau? Von einem Lua-Script?

Wenn von einem Addon, dann wird das nicht so "simpel" (zumindest nicht für einen kleinen Code-Block hier im Forum), da ja erst mal Lua initialisiert, die API registriert werden muss, die Deklarationen eingebaut usw.
Aber ich kann evtl. das die Tage mal zu einem Mini Demo-Projekt zusammenbauen.

[neo4a]

Zitat von ehX:

Zitat:

Kannst Du dazu vielleicht ein simples Beispiel posten?

Von was jetzt genau? Von einem Lua-Script?

Wenn es hilft, die Umsetzung innerhalb Deines Plugin-Systems besser zu illustrieren, dann auch das.