Puh, was man alles machen kann.
Ja, ist schon nett ...
Aber im Prinzip entscheidest du im OnEntry von TDataState.Fetching mit Hilfe der Methode "FetchData" welcher Zustand als nächstes kommt. Also TDataTrigger.Data oder TDataTrigger.Error.
Hmmm, wenn ich in den Status
Fetching komme, dann soll der Fetch-Prozess gestartet werden. Dieser kann irgendwann mit dem Trigger
Data oder
Error enden und der wird dann an die SM übergeben.
Es ist also keine Entscheidung, sondern ein eine Reaktion und der Status folgt dieser.
Als weiteren Punkt nehme ich mit, dass über den "DataAccessor", welcher der State Machine als anonyme Methode übergeben wird, je nach Anwendungsfall unterschiedliche Datenzugriffe möglich werden. Also je nachdem was als TSource und TResult festgelegt wird.
Jupp, du kannst einen String übergeben und dir damit ein Objekt irgendwo herholen (der String ist evtl. ein Dateiname und zurück kommt ein MemoryStream oder ein Text ...).
Ich suche eigentlich nur einen Ablauf, wenn nach einer Eingabe das Edit-Feld verlassen wird. Also das "Refetching" könnte ich mir sparen. Der Aufwand scheint mir trotzdem relativ hoch.
Wodurch was ausgelöst wird ist ja egal, man muss nur schauen, was es für Auslöser (Trigger) gibt und welche Statüsse (
) es gibt.
Setzt du diesen DataContainer universell ein?
Nö, den habe ich gerade mal zusammengehauen, sonst wär der etwas schöner
Benutzt du allgemein State Machines um z.B. Daten über Edit-Felder vom Bediener abzufragen und dann weiterzuverarbeiten?
Das kommt darauf an, was ich da wirklich will. Die SM alleine macht ja noch keinen vernünftigen Ablauf. Man kann nur einen Ablauf dort mit abbilden und auch einfach erweitern, umbauen, ergänzen.
Die SM wird man in den seltensten Fällen in freier Wildbahn erleben, sondern meistens (wie hier) eingebettet in einer anderen Klasse. Bei den Beispielen kann man das auch schön sehen.