Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
3 Antworten auf „GTMDatenbasis und Prelader“
Nachdem ich tiefer in den Komplex vorgedrungen bin plädiere ich dafür, die beteiligten Elemente komplett zu eliminieren.
Die GTMDatenbasis und der DAVPrelader dienen offensichtlich lediglich dazu, die View „SichtObjektZUsammenstellung“ und den Dialog „DatenIdentifikationGTM“ zu beschleunigen.
Die Funktion ist:
In der View „SichtObjektZusammenstellung“ werden Systemobjekte zusammengesammelt, die über den oben genannten Dialog ausgewählt werden.
Wenn die View mit dem enthaltenen „OK“-Button geschlossen wird, werden alle Listener, die sich an der Singleton-Instanz der View angemeldet haben (die auch besteht, wenn die View nicht angezeigt wird !!!) benachrichtigt, das Objekte ausgewählt wurden.
Das heißt der ganze Komplex erfüllt die Funktion: Gib mir die Möglichkeit, mich darüber informieren zu lassen, wenn irgendjemand, irgendwann, irgendwelche Objekte ausgewählt hat.
Was ich mit dieser Information anfangen soll und wie ich das in ein verwendbares Konstrukt umwandeln kann, ist mir noch nicht klar geworden.
Ich gehe davon aus, dass dieses Teil (außer beim Test des Rahmenwerks an sich) noch nie verwendet wurde!
Mit letzterer Feststellung haben Sie sicher Recht: das wurde nie verwendet.
Und wenn Sie sich nicht vorstellen können, wie man das realisierte Konstrukt irgendwie sinnvoll verwenden könnte, dann stimme ich Ihrem Vorschlag zu, es auch komplett zu entfernen.
So ‚was in der Art habe ich mir schon gedachtet (oder befürchtet). Ich bin daher mit beiden Vorschlägen einverstanden.
Der SystemObjekteAuswahlDialog war nach meiner Erinnerung für das da, was sein Name schon vermuten lässt: er sollte als zentrales Element vom Rahmenwerk für andere Plug-ins zur Verfügung gestellt werden, um dort Systemobjekte auswählen zu können (z. B. für das PuA-Plug-in), damit das nicht jedes Plug-in selbst machen muss. Der Dialog sollte wohl von außen konfigurierbar sein, damit er z. B. nur Systemobjekte eines bestimmten Typs anzeigt.
Aber das zentrale Problem war wohl (wie so oft): er hat nie richtig funktioniert und deshalb wurder er nirgends eingesetzt, stattdessen macht das jedes Plug-in jetzt selbst.
Nachdem ich tiefer in den Komplex vorgedrungen bin plädiere ich dafür, die beteiligten Elemente komplett zu eliminieren.
Die GTMDatenbasis und der DAVPrelader dienen offensichtlich lediglich dazu, die View „SichtObjektZUsammenstellung“ und den Dialog „DatenIdentifikationGTM“ zu beschleunigen.
Die Funktion ist:
In der View „SichtObjektZusammenstellung“ werden Systemobjekte zusammengesammelt, die über den oben genannten Dialog ausgewählt werden.
Wenn die View mit dem enthaltenen „OK“-Button geschlossen wird, werden alle Listener, die sich an der Singleton-Instanz der View angemeldet haben (die auch besteht, wenn die View nicht angezeigt wird !!!) benachrichtigt, das Objekte ausgewählt wurden.
Das heißt der ganze Komplex erfüllt die Funktion: Gib mir die Möglichkeit, mich darüber informieren zu lassen, wenn irgendjemand, irgendwann, irgendwelche Objekte ausgewählt hat.
Was ich mit dieser Information anfangen soll und wie ich das in ein verwendbares Konstrukt umwandeln kann, ist mir noch nicht klar geworden.
Ich gehe davon aus, dass dieses Teil (außer beim Test des Rahmenwerks an sich) noch nie verwendet wurde!
Mit letzterer Feststellung haben Sie sicher Recht: das wurde nie verwendet.
Und wenn Sie sich nicht vorstellen können, wie man das realisierte Konstrukt irgendwie sinnvoll verwenden könnte, dann stimme ich Ihrem Vorschlag zu, es auch komplett zu entfernen.
So ‚was in der Art habe ich mir schon gedachtet (oder befürchtet). Ich bin daher mit beiden Vorschlägen einverstanden.
Der SystemObjekteAuswahlDialog war nach meiner Erinnerung für das da, was sein Name schon vermuten lässt: er sollte als zentrales Element vom Rahmenwerk für andere Plug-ins zur Verfügung gestellt werden, um dort Systemobjekte auswählen zu können (z. B. für das PuA-Plug-in), damit das nicht jedes Plug-in selbst machen muss. Der Dialog sollte wohl von außen konfigurierbar sein, damit er z. B. nur Systemobjekte eines bestimmten Typs anzeigt.
Aber das zentrale Problem war wohl (wie so oft): er hat nie richtig funktioniert und deshalb wurder er nirgends eingesetzt, stattdessen macht das jedes Plug-in jetzt selbst.