Hi Leute,

ich gebe ehrlich zu, dass ich auf diesem Gebiet null Ahnung habe und hier etwas Schützenhilfe (Nachhilfe) für die einarbeitung in diese Thema suche.

Mir geht es um folgende Lösung:

Ich habe ein fertiges Programm, welches bei anwendern in Nutzung ist. Nun möchte ich das Programm um weitere Funktionen erweitern. Als Beispiel sei ein Personalverwaltung gegeben, welche ich um ein Planungstool erweitern möchte. Jetzt soll das so realisiert werden, dass mann dieses Tool nach installieren kann (neue Menüs, interaktion der neuen Programmteile mit der Hauptanwendung ...).
Für mich hätte das folgende Vorteile:
1. Alle Nutzer des Hauptprogrammes können weiter Updates bekommen, ohne dass man die neuen Tools verschenkt.
2. Das entsprechende Programm kann benutzerspezifisch an Hand seiner Module konfiguriert werden und der Anwender bekommt das, was er braucht und nicht was alles da ist (was er nicht braucht).

so was scheint gängige Praxis zu sein, aber ich weis nicht wie man das proggt.

Wenn mir einer helfen kann, währe toll.

Gruß oki

Du könntest die einzelnen Module in DLLs auslagern.
Die DLLs werden beim Start vom Hauptprogramm, das nur die Basissachen enthält, gesucht/gefunden und dann geladen.

Die DLLs exportieren alle eine Standardfunktion, die Informationen, wie z.B. Name, Version, Callback-Funktion, etc., an das Hauptprogramm weitergibt.

Über die Callback-Funktion kann dann das Modul vom Hauptprogramm gestartet werden.

Hi ste_ett,

Dank für die Antwort.

Nun hab ich aber gesehen, dass einige Programme die Menüs verändern. Ich habe mir letztens GExperts installiert (übriegens super Tool) und die haben sicher nicht dafür gesorgt, dass mein D5 da an was denkt.

Unberührt der Tatsache, dass es am besten wohl über DLL's geht, muß es Methoden geben die Ressourcen eines Programmes zu erweitern und mit neuen Programmmodulen zu koppeln.

Gruß oki

Die Informationen, die die DLL an das Hauptprogramm kann auch Informationen enthalten, wo du wie viele neue Einträge in Menüs, Popups und sonstige Kontrolls haben möchtest, inkl. Callback-Funktionen, für den Fall, dass man eine der neuen Einträge anklickt/auswählt.

Hi,

jo, scheint die Richtung zu sein die ich suche. Und wie funzt das nun mit den Menüs und Aufrufen und so? Bitte mal ein Stichwort für meine Suche. (Kleines Bsp. ist natürlich auch gerne gesehen)

Gruß oki

Zitat von oki:

Unberührt der Tatsache, dass es am besten wohl über DLL's geht, muß es Methoden geben die Ressourcen eines Programmes zu erweitern und mit neuen Programmmodulen zu koppeln.

Die gibt es

Ich benutze in meiner (kommerziellen) Anwendung dafür Packages.

Meine Anwendung ist komplett modular aufgebaut, der Anwendungsframe kann beliebig viele "Lösungsmodule" verwalten, die quasi eigene Anwendungen sind und die innerhalb des Hauptfensters ablaufen.

Hauptfenster und Module können in beide Richtungen kommunizieren, z.B. wird in dem Hauptfenster die DB-Verbindung hinterlegt (natürlich konfigurierbar) und kann von den Modulen z.B. über:
Query.Connection := xForm.XBASDBC; // xForm ist die Hauptform zugewiesen werden.

Über einen "Launcher" wird die Anwendung auf dem User-PC gestartet und fragt anhand des Rollenkonzepts ab, für welche Module (und für welche Formen innerhalb eines Moduls) der Anwender berechtigt ist und lädt ggf. bei vorhandenen neueren Versionen diese von einem Server nach.

Genauso funktioniert auch die Erstinstallation: Minimales Setup mit dem Launcher ist auszuführen (kann jeder User selbst übernehmen), anschließend steht diesem die "customizte" Version zur Verfügung.

Zum Umsetzungsaufwand: Ich habe dieses Framework in meiner Freizeit entwickelt und ca. 2,5 Jahre dafür gebraucht. Am Anfang habe ich auch mit DLLs rumgespielt aber feststellen müssen, dass diese für meine Belange absolut ungeeignet waren. Nachdem ich die "Technik" mit den Modulen raus hatte, begann dann der eigentliche "Denkaufwand": Wie verwalte ich meine Module, Berechtigungskonzept, Updateprozess, wie zeige ich diese an, Mehrsprachigkeit, etc.

Viele Grüße
Igotcha

Hi Igotcha,

deine erwähnten 2,5 Jahre Entwicklungszeit für dein modulares Konzept beeindrucken zwar, machen einen aber auch mächtig mutlos. Ich habe aber den Eindruck, dass dein gesamtes Projekt von Anfang an auf dieses Konzept aufgebaut ist. Dies ist bei mir leider nicht mehr machbar (außer ich schreibe alles neu ).
zum Glück habe ich nicht den Anspruch meine gesamte Anwendung modular aufzubauen, sondern nur einige wenige Module nachzuinstallieren. Wie gesagt, ich habe den Eindruck, dass das über "einfache Wege" gehen muß.

Gruß oki

Zitat von oki:

deine erwähnten 2,5 Jahre Entwicklungszeit für dein modulares Konzept beeindrucken zwar, machen einen aber auch mächtig mutlos.

Hi,
ich möchte hier gar nicht für Igotcha sprechen! Aber er hat es halt auch in seiner Freizeit gemacht und wie er sagte dauerte es so lange ein gutes Konzept zu erstellen, ein schlechtes geht deutlich schneller

Zitat von oki:

zum Glück habe ich nicht den Anspruch meine gesamte Anwendung modular aufzubauen, sondern nur einige wenige Module nachzuinstallieren. Wie gesagt, ich habe den Eindruck, dass das über "einfache Wege" gehen muß.

Dann solltest du dringend an deinem Anspruch arbeiten. An sich solltest du hier nicht denken: "Zum Glück möchte ich nur ..." sondern vielmehr darüber nachdenken, was du beim nächsten mal besser machen kannst (das wäre dann ein komplett modularer Aufbau). Modular arbeiten schadet nie und hat häufig Vorteile wie du sie hier siehst.
Jedenfalls ist keine Möglichkeit komplett trivial und mal nebenbei implementiert. Ich persönlich würde dir fast nahe legen, über ein sauberes Neu-schreiben nachzudenken, dank Modulen kannst du hier ja einzelne Teile nach und nach "portieren". Gerade wenn du noch etwas anderes einbaust empfehle ich dir es nicht überstürzt und zu einfach zu tun. Es ist hier mehr als eine Dll erforderlich! Du solltest dir also (egal wie einfach dir die Anfänge dann noch fallen oder eben nicht) gut Gedanken machen, wie du was löst.

Zu deinem eigentlichen Problem, dies lässt sich in mehrere Teile zerlegen. Der eine Teil wäre das Laden der DLL. Ich denke hier ist das wichtigste schon fast gesagt. Dann gibt es natürlich noch die DLLs, über die kann man wohl erst reden wenn der Rest feststeht, bleibt also noch die Schnittstellen deines Programms.
Wie du (im Vergleich mit der Delphi IDE) richtig erkannt hast, muss dein Programm Schnittstellen anbieten, auf die ein anderes Programm / eine DLL zugreifen kann. Hier musst du dir also überlegen was genau deine Erweiterungen machen dürfen und was nicht. Das ganze solltest du möglichst nicht irgendwann erweitern müssen, denn dann kommst du schnell in das Problem der inkompatiblen Versionen.
An sich lohnt es sich, wenn du dir sehr abstrakt eine Liste erstellst, was erlaubt sein sollte. Mit abstrakt meine ich hier, dass du nicht den Zugriff auf Formular XY Eigenschaft Z nimmst, sondern nur die Möglichkeit vorsiehst z.B. einen Eintrag im Menü unterzubringen. Wo das Menü herkommt sollte deinem Plugin / Modul natürlich vollkommen egal sein.
Diese Möglichkeiten, die du hier findest sind sozuasgen der Umfang deines SDK. Du musst jetzt in einem eigenen Modul (würde ich dir zu raten) oder mehren Möglichkeiten anbieten, diese Mehtoden zu nuzten.
Ich gehe hier einfach mal davon aus, dass du dabei deine DLLs komplett in Delphi erstellst, der Zugriff auf Delphi Klassen also nicht das Problem sein sollte.
Hier könntest du dann eine abstrakte Basisklasse schaffen, die du an die Initialisierung der DLL übergibst. Ein unvollständiges kurzes Beispiel wäre in der Art :

zusammenfalten · markieren

Delphi-Quellcode:

  TAbstractMenue = class(TObject)
    public
      procedure addEntry(...);
  end;

  TDeinPlugin = class(TObject)
    public
      procedure init(const Menue: TAbstractMenue);
  end;

...

procedure TDeinPlugin.init(const Menue : TAbstractMenue);
begin
  // diese Methode müsste dann beim Laden des Plugins aufgerufen werden
  // (das Entladen nicht vergessen!)
  // Wer auch immer die DLLs lädt, darf dann ruhig eine konkrete Klasse kennen,
  // die dann entsprechende Möglichkeiten (z.B. das Eintragen in ein Menü) zur
  // Verfügung stellt.
  // Hier kannst du dann über diese Eigenschaften festlegen, wo der Eintrag hin kommt
  // wie der heißt und welche Methode wann aufgerufen wird.
  // du siehst, dass alles musst du in der abstrakten Klasse berücksichtigen, also
  // gut über den Umfang nachdenken.
end;

Natürlich musst du für alle Möglichkeiten die du anbieten möchtest etwas in der Richtung vorsehen. Jetzt gibt es noch eine weitere Sache, die du vielleicht behandeln möchtest: Ereignisse. Wenn in deinem Programm etwas passiert, kann es sein, dass sich eines deiner Module dafür interessiert. Hier könntest du natürlich ein eigenes Ereignis bereitstellen, viel schöner ist es aber hier auf das Observer-Pattern (einfach mal danach suchen) zu verwenden. Grob gesagt gibt es als Lösungsmöglichkeit vor, dass du bestimmte Objekte die etwas beobachten wollen (die Observer) bei dem zu Beobachtendem (Observable) registrieren können. Du hast etwas wie add/removeObserver. Ein Observer muss dann ebenfalls ein Interface oder eine abstracte Klasse sein, die halt Methoden enthält, die beim eintreten eines Ereignisses aufgerufen werden. Das ist das OOP Pendand zur Callback-Funktion. Der Vorteil liegt darin, dass du hier mit der Kapselung/dem Objekt arbeiten kannst, also die Vorteile der OOP behälst. So kannst du hier die Verwaltung z.B. über eine TObjectList vornehmen.

Ja, hoffe du kannst einen Teil davon verwenden. Wie gesagt, es ist nicht ganz trivial und sollte nicht halbherzig gemacht werden.

Gruß Der Unwissende

Hi Unwissender,

ich habs geahnt und doch nicht geglaubt. Aber ohne Arbeit gehts dann doch wieder nicht. Hier auch erst mal herzlichen dank für deine umfangreiche Antwort.
Ich bin jetzt so langsam auch davon überzeugt, dass ich den langen Weg nehmen muß. Zum ende des Jahres muß ich eh größere Teile meines Projektes überarbeiten. Bis dahin kann ich mir ja schon mal entsprechen Gedanken zu meinem Modul-Konzept machen.
Dank auch für den Hinweis mit den Observer-Pattern. damit werd ich mich mal beschäftigen. Sollte ich dazu Fragen haben, werde ich dafür einen neuen thread aufmachen.

also, dank und Gruß

oki

Moin oki,

ich hab letzten Sommer fuer eine Anwendung dasselbe gemacht, und ca. einen Monat dafuer gebraucht. Einen Monat inklusive der Erkenntnis dass DLLs dafuer ungeeignet sind. Wenn dein Modul z.B. Komponenten anzeigen soll, dann wirst du dich ewig abaergern. Mein Tipp: nimm Packages, die du dynamisch nachlaedst. Hier siehst du z.B. einen Ansatz, an das Problem heranzugehen. Trivial ist es bestimmt nicht, aber es kann dir viel Arbeit ersparen sobald es mal fertig ist.

Greetz
alcaeus