Verwenden von Reaktoren für dynamische Regeln

Reaktoren für dynamische Regeln generieren oder entfernen dynamische Regeln automatisch bei Änderungen an anderen dynamischen Regeln. Diese Aktionen werden durch Regeln gesteuert und haben daher Zugriff auf alle zum jeweiligen Zeitpunkt vorliegenden Regeln im Modell. Reaktoren bieten eine vom Host unabhängige Funktionalität, d. h. ihre Funktionsweise ist auf allen Hosts, auch bei serverbasierten Implementierungen, identisch.

Reaktoren werden durch bestimmte Vorgänge dynamischer Regeln ausgelöst. Dadurch sind Reaktoren gerade in einem Laufzeitkontext während einer Endbenutzersitzung besonders nützlich. Diese mit dynamischen Regeln verknüpften Vorgänge sind genau diejenigen Vorgänge, die ein Endbenutzer normalerweise über eine benutzerdefinierte Benutzeroberfläche (UI) veranlasst. Zu Testzwecken können Sie diesen Prozess in der Entwicklungsumgebung simulieren. In erster Linie aber sollen Reaktoren Ihnen als Entwickler die Möglichkeit geben, eine regelbasierte Methode zur Verbesserung der durch den Endbenutzer veranlassten Modelländerungen bereitzustellen.

Für jede Art von Änderung an einer dynamischen Regel, wie das Erstellen, Ändern oder Löschen, können Sie Reaktormethoden definieren, die Intent anweisen, zu den angegebenen Zeiten weitere Aktionen auszuführen. Bei den Reaktormethoden handelt es sich um ganz normale Intent-Methoden, von denen die meisten eine Liste mit Aktionslisten zurückgeben. Die Reaktormethoden können das Modell zum Zeitpunkt der Änderung untersuchen und andere Regeln für die Erstellung eines Teils oder aller Aktionslisten referenzieren. Dabei gelten für deren Bereich nur wenige Einschränkungen. Wenn ein Reaktor eine leere Liste { } zurückgibt, wird keine Aktion ausgeführt.

Reaktoren werden immer in Verbindung mit einer benutzerdefinierten UI verwendet und nicht aus der Entwickler-UI (außer zu Testzwecken). Regelbasierte Reaktoren haben gegenüber der festen Codierung bestimmter Verhaltensweisen in die UI verschiedene Vorteile:

• Bei den Regeln handelt es sich um ein Komplettpaket, und selbst bei einem Wechsel der UI steuern Ihre Regeln nach wie vor ein vollständiges und genaues Modell.
• Die UI kann erweiterbar sein. Verschiedene Objekttypen können unterschiedlich reagieren, und sie können ohne Bearbeitung des UI-Codes geändert bzw. hinzugefügt werden.
• Da sich der Reaktor direkt in den Regeln und somit in demselben Kontext befindet, lassen sich notwendige Änderungen daran leichter durchführen.

Anmerkungen

• Alle Reaktorregeln sind Methoden, die keine Argumente akzeptieren. Dies mag zwar ungewöhnlich erscheinen, war aber eine gezielte Designentscheidung. Um bei jeder Änderung neu aufgerufen zu werden, müssen Reaktoren aus dem Cache entfernt werden. Aber wir haben sehr bald festgestellt, dass Benutzer (wir selbst nicht ausgeschlossen) häufig das Flag Uncached vergessen haben, weshalb der Reaktor auf mysteriöse Weise ab der zweiten Änderung nicht mehr funktioniert hat. Dieses Problem vermeiden wir, indem wir erzwingen, dass alle Reaktoren Methoden sind.
• Zwischen den von Ereignis-Handlern erstellten dynamischen Regeln und der Reaktormethode bzw. irgendetwas anderem, von dem der Reaktor abhängig ist, besteht keine Abhängigkeit.