Add-On erstellen, das auf die Funktion im Hauptprogramm zugreift?

[romber]

Hallo!

Ich habe da ein Projekt bestehend aus zwei Teilen: ein Server und ein Client.

Der Server bekommt die Daten von mehreren Webservices, wandelt die Daten in einen gemeinsamen XML-Format um und verteilt an die verbundene Clients. Der Client verbindet sich mit dem Server, erhält die XML-Daten, wandelt jeden Datensatz in ein Objekt um visualisiert diesen Objekt nach Kundenvorgaben. Für die Umwandlung der Daten und die anschließende Prüfung und Visualisierung ist eine Funktion im Client zuständig, die XML-String (UTF-8) als Parameter erhält. Funktioniert alles auch ganz gut.

Nun möchte ich dem Benutzer die Möglichkeit bieten, auch von anderen Datenquellen die Daten zu beziehen. Am besten soll das in Form von Add-Ons geschehen. Dabei soll sich der Add-On selbst für die Datenbeschaffung (Datenträger, Internet oder wo auch immer), Übertragung, Verschlüsselung usw. kümmern und mit dem Hauptprogramm nur über diese eine Funktion kommunizieren, die vom Add-On die XML-Daten erhält und wie gewöhnt weiter verarbeitet und visualisiert. In den Einstellungen des Hauptprogramms unter dem Reiter "Add-Ons" fügt man die Add-Ons hinzu und kann auch für jeden Add-On spezifische Einstellungen vornehmen, z.B. Benutzername und Kennwort eingeben, falls der Add-On die Daten von einem Webservice beschafft. So ist der Plan.

Wie realistisch ist das alles? Wie soll der Add-On am besten aussehen? Soll das eine DLL sein oder was am besten? Wie würdet Ihr das machen?

Im Voraus vielen Dank!

[mkinzler]

Kann man mit Dlls oder Bpls implementieren. im 1. Fall halt prozedural.

[Der schöne Günther]

Das Programm ("Client") verbindet sich doch mit dem Server, die Verbindung bleibt offen, und immer wenn der Server etwas interessantes hat, schickt er diese ohne vorher aufgefordert zu werden, richtig?

Ich sehe nicht, inwiefern denn die Methode, die Ursprungsdaten nicht von irgendwelchen Webservices dort draußen, sondern beispielsweise von der Platte, derart unterscheidet, nicht auch so ein Server sein zu dürfen -

Ich finde das Hauptprogramm kann doch mehr oder weniger so bleiben wie es ist und sich immer mit einem Server unter einer festgelegten Adresse (per HTTP?) verbinden. Der Standardweg scheint ja weiterhin der zu bleiben, sich über den eingangs genannten Server die Daten schicken zu lassen, der Benutzer soll aber über seine bekannte grafische Client-Oberfläche jetzt auch andere Quellen auswählen können. Ich würde die jetzt zu bastelnden Datenbeschaffer ebenso als (lokal laufenden) Server aufsetzen auf den sich genauso verbunden wird (und Benutzername/Passwort gesendet wird), wie vorher auch.

Wenn der lokal laufende Server nur auf 127.0.0.1 lauscht hängt sich die Windows Firewall auch nicht dazwischen. Der Button auf der Client-Oberfläche muss eigentlich nur den Server (normaler Prozess) starten (am besten ohne sichtbares Fenster) und bei Bedarf (oder bei Client Ende) wieder beenden.

So sehe ich das.


Nur habe ich Probleme, den Titel zu verstehen: Wo greift denn das Add-On auf Funktionen des Client zu? Ich sehe bislang keine Callbacks von neuen Teil zurück in den "alten" Client...

[romber]

Habe auch an DLL gedacht. Habe aber noch keine klare Vortellung, wie die interaktion zwischen dem Hauptprogramm und dll ablaufen soll. Der Add-On soll dem Hauptprogramm mitteilen, welche Angaben von Benutzer nötig sind, z.B. Benutzername und Kennwort. Das können aber auch andere Add-On-Spezifische Einstellungen sein. Der Add-On muss auch irgendwie die Daten an die Funktion im Hauptprogramm übergeben können. So was in der Art habe ich noch nie gemacht. Wir würde Ihr es machen, worauf muss ich besonders achten?

[romber]

Zitat von Der schöne Günther:

Das Programm ("Client") verbindet sich doch mit dem Server, die Verbindung bleibt offen, und immer wenn der Server etwas interessantes hat, schickt er diese ohne vorher aufgefordert zu werden, richtig?

Genau so ist es. Ein weiterer Thread überwacht die Verbindung und baut die bei Bedarf wieder auf.

Zitat von Der schöne Günther:

DIch würde die jetzt zu bastelnden Datenbeschaffer ebenso als (lokal laufenden) Server aufsetzen auf den sich genauso verbunden wird (und Benutzername/Passwort gesendet wird), wie vorher auch.

Die Einstellungen des Add-Ons würde ich gerne über den Client festlegen. Es können übrigens nicht nur Benutzerdaten sein, sondern auch andere diversen Parameter, z.B. wie oft soll die Anfrage stattfinden oder so was in der Art. Aber wenn ich mir so überlege, währe das auch kein Problem in diesem Fall.

Zitat von Der schöne Günther:

Nur habe ich Probleme, den Titel zu verstehen: Wo greift denn das Add-On auf Funktionen des Client zu? Ich sehe bislang keine Callbacks von neuen Teil zurück in den "alten" Client...

Die Daten, die über fest verbaute Datenquellen ankommen werden an eine Funktion übergeben, die dann alles weitere erledigt. Der Add-On muss also auch diese Funktion aufrufen.

[mjustin]

Zitat von romber:

Wie realistisch ist das alles? Wie soll der Add-On am besten aussehen? Soll das eine DLL sein oder was am besten? Wie würdet Ihr das machen?

Ein paar Anregungen sind hier zu finden:

http://stackoverflow.com/questions/3...delphi-program

Eine Open Source Lösung ist der JvPluginManager aus der Jedi JCL , der ein Grundgerüst für DLL (und BPL) Plugins bereitstellt.

http://stackoverflow.com/a/366079/80901
http://www.delphipraxis.net/901951-post.html

[romber]

@mjustin

Vielen Dank für diese Link, sehr interessant!

Die von dem Dem schönen Günther vorgeschlagene Lösung, die Add-Ons als Server zu implementieren, ist eine gute Idee. Die wäre auch sehr einfach zu realisieren. Aber wenn man als alternative noch die DLL-Schnittstelle anbieten möchte, wie greift eine Funktion in der DLL auf die Funktionen im Hauptprogramm zu?

Sagen wir, ich habe jetzt im Hauptprogramm eine Function, die als Parameter einen String erwartet. Dieses String wird dann zu einem Objekt umgewandelt, geprüft/gefiltert und dann dem Benutzer angezeigt. Wenn ich jetzt eine zusätzliche überladene Variante dieser Funktion erstelle, in der ich alle unpassende Datentypen durch Windows API kompatible Datentypen ersetze, wie kann meine DLL auf diese Funktion zugreifen?

[BUG]

Zitat von romber:

Wenn ich jetzt eine zusätzliche überladene Variante dieser Funktion erstelle, in der ich alle unpassende Datentypen durch Windows API kompatible Datentypen ersetze, wie kann meine DLL auf diese Funktion zugreifen?

Indem du dem Add-On die Adresse der Funktion gibst (z.B. als Parameter einer Initialisierungsfunktion).
Wenn du das mit mehreren Funktionen machen willst, würde ich so etwas wie ein Interface benutzen.


Solltest du wirklich DLLs und Server unterstützen wollen, würde ich mich erst einmal auf die DLL-Schnittstelle beschränken und mögliche Verbindungen zu Servern über entsprechende DLL-Add-Ons ermöglichen.

[romber]

[QUOTE=BUG;1216123]

Zitat von romber:

Indem du dem Add-On die Adresse der Funktion gibst (z.B. als Parameter einer Initialisierungsfunktion).
Wenn du das mit mehreren Funktionen machen willst, würde ich so etwas wie ein Interface benutzen.

Es wird erst mal nur eine Funktion aus dem Hauptprogramm in DLL aufgerufen. Ich denke, ich probiere es erst mal mit der esten Variante. Nennt sich das Callback-Funktion oder ist mit der Weitergabe der Adresse der Funktion an den Add-On etwas anderes gemeint?

[BUG]

Zitat von romber:

Nennt sich das Callback-Funktion oder ist mit der Weitergabe der Adresse der Funktion an den Add-On etwas anderes gemeint?

Jup, Callback-Funktion würde passen.
Ich weiß ja nicht, was du in der Funktion (in der DLL) so anstellst. Wenn die einen Thread erstellt, der dann irgendwann (nachdem die Funktion zurückgekehrt ist) die "Callback"-Funktion aufruft, würde ich nicht unbedingt mehr von Callback sprechen. Aber das ist Erbsenzählerei