PlugIns ermöglichen

[wma]

Abend,

kann mir jemand eine vorstellung geben, wie ich plugins für mein "projekt" ermögliche, sodass mein code verändert werden kann und man den code mit skripten in einem plugin-ordner dennoch erweitern kann?
Wie könnte ich dies anstellen.

Bsp.
Habe eine Klasse class Schreibtisch mit Methoden, die die Höhe, Tiefe, Breite abrufen. Jetzt möchte aber xyz im Projekt diese Klasse mit einem PlugIn beeinflussen, da die Daten für Höhe, Tiefe und Breite aus eigenen Produktdatenblättern geholt werden müssen. D.h. meine Klasse muss jedesmal gucken, ob sie überschrieben wird, oder wie könnte ich das anstellen?

Gruß

[Robert Kabinger]

Abend,

Grüss dich!

kann mir jemand eine vorstellung geben, wie ich plugins für mein "projekt" ermögliche, sodass mein code verändert werden kann und man den code mit skripten in einem plugin-ordner dennoch erweitern kann?

Ich verstehs nicht, sorry.

Habe eine Klasse class Schreibtisch mit Methoden, die die Höhe, Tiefe, Breite abrufen. Jetzt möchte aber xyz im Projekt diese Klasse mit einem PlugIn beeinflussen, da die Daten für Höhe, Tiefe und Breite aus eigenen Produktdatenblättern geholt werden müssen. D.h. meine Klasse muss jedesmal gucken, ob sie überschrieben wird, oder wie könnte ich das anstellen?

Versteh ich auch nicht.

Könntest du bitte noch ein Beispiel oder eine andere Erklärung für dein Problem posten?

Mfg kawinga

[wma]

Hallo,

ich bastel ein "Projekt", in dem in jeder Datei eine Klasse liegt. Nun möchte ich einem "Enduser" die Möglichkeiten PlugIns für mein "Projekt" zu schreiben. Brauche also eine PlugIn-Schnittstelle für mein "Projekt".

Nun geht es darum, wie ich so etwas anstellen könnte.

Folgende Idee:

Meine Klassen werden von der übergeordneten Projekt-Klasse durch eine Autoload funktion includiert. Wenn ich nun innerhalb dieser autoload-Funktion überprüfe, ob ein PlugIn in dem Ordner mit dem Klassen-Namen besteht und dann diese Klasse includiere, die die ursprüngliche extended.

Also
class Schreibtisch
wird angefordert. Autoload-Funktion erkennt, dass ein PlugIn existiert, das die Schreibtisch-Klasse extended und inkludiert diese?

Gruß

[Peter Pan]

Hi!

So ganz verstehe ich Dein Anliegen (noch?) nicht.

Was hast Du denn bisher konkret unternommen?

Bedenke bitte, dass Vererbung kein Allheilmittel ist.

off:PP

[wma]

Hallo,

bisher habe ich ein "Projekt", das mit den Funktionalitäten, die es bereitsellt nur die bereits enthaltenen Klassen so braucht, wie sie eben schon exisiteren.

Möche jemand zusätzliche Funktionalität einbinden, sollte dies möglichst gehen ohne den Code des Projekts direkt zu ändern sondern diesen zu updaten mit einem PlugIn. Sprich durch PlugIns soll die Funktionalität erweitert werden können ohne die Kernfiles des Projektes ändern zu müssen.

Meine einzig annähernde Idee war eben, einen PlugIn-Ordner einzuführen, in dem mögliche PlugIns liegen müssen. Diese müssen eine komplette schon bestehende Klasse des Projektes extenden, sodass die Grundfunktionalität weiterhin gewehrleistet wird. Wie ich das genau umsetzten könnte weiß ich eben nicht oder wie ich es anders lösen könnte.

Gruß

[Blaubart]

Tach.

kann mir jemand eine vorstellung geben, wie ich plugins für mein "projekt" ermögliche, sodass mein code verändert werden kann und man den code mit skripten in einem plugin-ordner dennoch erweitern kann?

Meiner Ansicht nach schmeißt Du hier zwei Sachen durcheinander: Vererbung und Plugins. Klar, Du kannst natürlich eine Basisklasse für Plugins vorgeben, die dann der Pluginschreiber als Vorlage für sein Plugin benutzt. Irgendeine verbindliche Vorgabe für die Schnittstelle zwischen Hauptprogramm und Plugin ist sogar zwingend notwendig, sonst könnte Dein Programm ja nicht viel damit anfangen. Was Du weiterhin beschreibst, klingt allerdings nicht nach einem Plugin, sondern kommt eher der Änderung Deines "Basiscodes" gleich.

Plugins hingegen klinken sich üblicherweise an definierten Stellen in ein Hostprogramm ein. Welche Stellen das sind und welche Daten das Plugin serviert kriegt, legst Du als Programmierer dieses Programms fest. Beim Starten des Programms werden die Plugins in eine Liste eingetragen, auf die das Hauptprogramm später beim Erreichen der Einklinkpunkte wieder zugreift. Normalerweise läuft das ungefähr so:

Dein Programm stellt eine gewisse Grundfunktionalität zur Verfügung, also meinetwegen das Öffnen und Abspielen einer Audiodatei. Darüber hinaus bietet es Plugins Einstiegspunkte an, an denen sie z. B. die Audiodaten zur Verfügungs gestellt bekommen, um irgendwas damit zu machen. Das Programm startet beispielsweise vor dem Senden der Daten an die Audiohardware nacheinander alle Plugins aus seiner Pluginliste, verarbeitet deren Rückgabewerte, räumt wieder auf und macht dann weiter im normalen Programmablauf. So ein Plugin könnte jetzt z. B. ein Equalizer sein, der die Audiodaten filtert oder ein Spektralanalysator, der sie in den Frequenzbereich transformiert und graphisch darstellt.

Andere Möglichkeiten wären z. B. Einstiegspunkte beim Öffnen der Dateien. Dort könnte ein Plugin die Dateinamen übergeben bekommen und eine Liste der zuletzt geladenen Dateien verwalten. Hier siehst Du auch, daß es sinnvoll sein kann, getrennte Listen für die unterschiedlichen Einstiegspunkte zu verwalten. Der Equalizer soll ja nur gezielt vor der Ausgabe aufgerufen werden, während die Dateiliste mit Audiodaten gar nichts zu schaffen hat.

Um's kurz zu machen: Du bietest in Deinem Programm "Steckplätze" für externe Geräte (die Plugins) an. Falls ein Gerät am Steckplatz angeschlossen ist, sendest Du zum entsprechenden Zeitpunkt Daten, die das Gerät verarbeitet und evtl. verändert zurück an Dein Programm schickt. Das angeschlossene Gerät muß dazu nichts an Deinem Programm ändern; das ist der springende Punkt.