Hallo Uwe,

ich habe gerade mal durch deinen Vortrag geschaut.
Vielen Dank für die sehr schöne Session, da zeigst Du wirklich perfekt wie man von den ollen Events weg zu einem schönen, schlanken Design kommen kann.
Alles sehr schön sauber getrennt und modular lauffähig, fast schon ein halbes MVVM

Was mich da umtreibt sind die Validators, wo es laut Deiner Aussage auf die Reihenfolge der AddXxx Einträge ankommt.
Das fände ich als einzige Stelle verbesserungswürdig, um solche blöden Fehler sauber abzufangen.


Was ich mich frage ist, ob man nicht die Reihenfolge der AddXxx während des Aufrufs testen kann und
bei falscher Reihenfolge von AddValidator eine Exception werfen kann.

Weil Du in erster Linie class helper benutzt hast ist durch das modulare Design wohl keine einfache Abfrage möglich, welcher Oberserver/Validator dem Control bereits zugewiesen wurde.
Das Verwenden von Interposern, um irgendwelche Variablen zu den Controls hinzuzufügen, ist auch nicht so elegant.

Im letzten Teil hast Du dann im TObservableDataWrapper diese Observer zusammengefasst, das würde einen solchen Test wohl ermöglichen,
aber packt natürlich wieder verschiedenen Dinge zusammen.
Dieser Wrapper sollte solche Probleme mit der Reihenfolge doch abfangen können.

Gibt es da eine schöne Lösung die jeweils zu jedem Control gehörenden Oberserver/Validatoren zu ermittlen,
oder ist das vielleicht schon in Deiner Lösung drin ?
Das Video ging jetzt schön flott, ich muss da sicher nochmal in Ruhe reinschauen, wird es die verschiedenen Ausbaustufen nochmal separat auf deinem GitGub-Account geben ?

Zitat von Rollo62:

Was mich da umtreibt sind die Validators, wo es laut Deiner Aussage auf die Reihenfolge der AddXxx Einträge ankommt.
Das fände ich als einzige Stelle verbesserungswürdig, um solche blöden Fehler sauber abzufangen.

Also, erstmal ist es nicht unbedingt ein Fehler, einen Observer vor einem Validator zu registrieren. Es kommt halt darauf an, was ich mit dem Observer erreichen will. Der Observer könnte z.B. jede Eingabe loggen und möchte da vielleicht auch die ungültigen Eingaben mitbekommen. Dann muss sogar der vor dem Validator kommen.

Im gezeigten Fall wird der Wert in die Instanz übertragen, aber das soll nur für gültige Werte passieren. Wenn man jetzt dort nochmal die Abfrage macht, kann der Validator ja auch später kommen:

markieren

Delphi-Quellcode:

  MyStringEdit.AddObserver(procedure(AValue: string) begin if Data.IsMyStringValidNoMsg(AValue) then Data.MyString := AValue end);
  MyStringEdit.AddValidator(Data.IsMyStringValid);

Zitat von Rollo62:

Was ich mich frage ist, ob man nicht die Reihenfolge der AddXxx während des Aufrufs testen kann und
bei falscher Reihenfolge von AddValidator eine Exception werfen kann.

Das ist sicher aktuell nicht so einfach möglich, da ja am Ende alle Observer von TCustomEditObserver abgeleitet sind und sich lediglich durch den Code im FOnNotifyValue unterscheiden.
Leider kann man auch keine Prioritäten für die Observer mitgeben, da die in einem private Dictionary verwaltet werden und man an die jeweiligen Listen nicht wirklich herankommt.

Zitat von Rollo62:

Weil Du in erster Linie class helper benutzt hast ist durch das modulare Design wohl keine einfache Abfrage möglich, welcher Oberserver/Validator dem Control bereits zugewiesen wurde.
Das Verwenden von Interposern, um irgendwelche Variablen zu den Controls hinzuzufügen, ist auch nicht so elegant.

Die class helper sind da ja aus einem bestimmten Grund: TCustomEdit ist die Basisklasse für eine ganze Reihe von Controls, die nun alle mit dem class helper abgedeckt werden. Eine Ableitung oder ein Interposer müsste ja für jede dieser Ausprägungen erfolgen.

Zitat von Rollo62:

Im letzten Teil hast Du dann im TObservableDataWrapper diese Observer zusammengefasst, das würde einen solchen Test wohl ermöglichen,
aber packt natürlich wieder verschiedenen Dinge zusammen.
Dieser Wrapper sollte solche Probleme mit der Reihenfolge doch abfangen können.

Das sind ja auch selbst geschriebene Klasse, die auch noch eine eigene TObserver-Ableitung verwenden. Da könnte man eventuell was machen, aber das hilft nicht bei den Control-Observern.

Zitat von Rollo62:

Gibt es da eine schöne Lösung die jeweils zu jedem Control gehörenden Oberserver/Validatoren zu ermittlen,
oder ist das vielleicht schon in Deiner Lösung drin ?

Nein, und ich kann da auch im Moment keine Möglichkeit entdecken. Wie oben schon erwähnt, kann man einen registrierten Observer nicht mehr als Validator erkennen.

Zitat von Rollo62:

Das Video ging jetzt schön flott, ich muss da sicher nochmal in Ruhe reinschauen, wird es die verschiedenen Ausbaustufen nochmal separat auf deinem GitGub-Account geben ?

Die Schritte aus den CodeRage-Sessions gibt es in einem separaten Repo, unabhängig von der CmonLib: https://github.com/UweRaabe/CodeRageDE2022

(Github Source im YouTube Video verlinkt. Danke!)

Zitat von Uwe Raabe:

Zitat von Rollo62:

Gibt es da eine schöne Lösung die jeweils zu jedem Control gehörenden Oberserver/Validatoren zu ermittlen,
oder ist das vielleicht schon in Deiner Lösung drin ?

Nein, und ich kann da auch im Moment keine Möglichkeit entdecken.

Es gibt immer einen Weg: Add priority to observers to better control execution order

Hallo Uwe,

ja super, das macht die Sache noch runder und kann man sicher an zig Stellen gut gebrauchen.

Danke für die Mühe, schaue ich mir nächste Woche nochmal genauer an.