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:
Delphi-Quellcode:
MyStringEdit.AddObserver(procedure(AValue: string) begin if Data.IsMyStringValidNoMsg(AValue) then Data.MyString := AValue end);
MyStringEdit.AddValidator(Data.IsMyStringValid);
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.
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.
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.
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.
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