Jeder Reaktor für dynamische Regeln wird durch eine Änderung ausgelöst. Es gibt drei Arten von Änderungen: Erstellen, Ändern und Löschen. Da die Erstellung einer dynamischen Regel eine Änderung einer nicht-dynamischen Regel in einem Design sein kann, können Erstellung und Änderung nicht unterschieden werden und werden vom selben Reaktor verarbeitet.
Intent verwendet dynamische Regeln für viele Zwecke im Hintergrund. Dabei unterliegen nicht alle Verwendungen Reaktoren. Reaktoren werden nur in bestimmten Situationen aktiviert. Beispiel: Das Erstellen einer Regel über die API Part.CreateDynamicRule aktiviert einen Reaktor, der Vorgang Rückgängig, bei dem genau diese Regel entfernt (gelöscht) wird, jedoch nicht. Die Vorgänge "Rückgängig" und "Wiederherstellen" aktivieren den Reaktor nicht. Es gibt verschiedene Situationen, in denen Reaktoren unterdrückt werden.
Wenn an einer dynamischen Regel eine Änderung vorgenommen wird, überprüft Intent, ob Reaktoren aufgerufen werden müssen. Ist dies der Fall, wird nach Reaktoren gesucht, die einen Prozess mit gleichem Namen verwenden. Bei grundlegenden Regeln wird der Name aus dem Regelnamen gefolgt von einem Unterstrich und dem Namen des Triggers gebildet. Bei untergeordneten Regeln entsprechen die Namen den Namen der Trigger. Sie müssen im Bauteil vorhanden sein. Darüber hinaus verfügen alle Trigger über einen entsprechenden "allow"-Namen, der verwendet werden kann, um die Änderung verhindern. Wenn kein entsprechender Name gefunden wird, erfolgt keine weitere Aktion.
Wenn ein entsprechender "allow"-Name gefunden wird, wird er überprüft, um festzustellen, ob die Änderung durchgeführt werden soll. Wenn nicht vorhanden, ist das Vorgabeverhalten, die Änderung zuzulassen. Die allow-Methoden geben immer einen booleschen Wert, keine Aktionsliste zurück. Wenn zugelassen, wird überprüft, ob die entsprechende Reaktormethode vorhanden ist.
Alle non-allow-Reaktoren geben eine "Aktionsliste" zurück. Diese ist in Form einer Liste von Aktionen strukturiert, von denen jede eine Eigenschaftsliste ("PLIST") mit Namen und Wertpaaren darstellt. Bei den zulässigen Namen handelt es sich um eine Funktion des tatsächlichen Reaktortyps. Sie müssen jedoch immer :action gefolgt von :CreateDynamicRule, DeleteDynamicRule oder CreateDynamicPart enthalten. Das Löschen eines dynamischen Bauteils erfolgt durch DeleteDynamicRule. In der Liste kann sich eine beliebige Anzahl von Aktionen befinden, sodass eine einzelne Regeländerung eine beliebige Anzahl weiterer Änderungen nach sich ziehen kann.
Eine Aktionsliste wird nach Erhalt verarbeitet. Bei Regeln, die von einer Aktion betroffen sind, kann es vorkommen, dass diese selbst von Reaktoren verarbeitet werden. Daher kann eine rekursive Kaskade von Änderungen auftreten. In dieser potenziellen Komplexität entstehen die meisten Probleme mit Reaktoren. Die Verarbeitung von Reaktoren findet nicht innerhalb einer einzelnen äußeren Intent-Auswertung, sondern in einer möglicherweise tiefen Struktur der Kompilierung von dynamischen Regeln statt. Aus diesem Grund gibt es für Entwickler nur sehr wenig Unterstützung beim Debuggen.
| Regel | Wird aufgerufen | Gibt Folgendes zurück |
|---|---|---|
| <ruleName>_allowModify? | Vor der Bearbeitung von <ruleName> | Boolescher Wert, der angibt, ob Änderungen zulässig sind |
| <ruleName>_preModify | Vor der Bearbeitung von <ruleName> | Liste mit einer Reihe von durchzuführenden Aktionen |
| <ruleName>_postModify | Nach der Bearbeitung von <ruleName> | Liste mit einer Reihe von durchzuführenden Aktionen |
| <ruleName>_allowDelete? | Vor dem Löschen von <ruleName> | Boolescher Wert, der angibt, ob Löschen zulässig ist |
| <ruleName>_preDelete | Vor dem Löschen von <ruleName>. Wenn <ruleName> eine untergeordnete Regel ist, tritt diese Aktion vor deleteSelf-Triggern auf. | Liste mit einer Reihe von durchzuführenden Aktionen. Der Reaktor kann die Regel referenzieren. |
| <ruleName>_postDelete | Nach dem Löschen von <ruleName>; wenn <ruleName> eine untergeordnete Regel war, tritt diese Aktion nach deleteSelf-Triggern auf | Liste mit einer Reihe von durchzuführenden Aktionen. Der Reaktor kann die Regel nicht referenzieren, es sei denn, sie schattiert eine Designregel. |
Die folgenden Trigger und deren Reaktoren werden verwendet, um anzugeben, wenn dynamische Bauteile hinzugefügt und gelöscht werden. Diese Reaktoren werden normalerweise in dem Design des Bauteils, das hinzugefügt oder gelöscht wird, als "Designregeln" (nicht-dynamisch) codiert.
| Regel | Wird aufgerufen | Gibt Folgendes zurück |
|---|---|---|
| preCreateSelf | Unmittelbar nach dem Erstellen des Bauteils | Liste mit einer Reihe von durchzuführenden Aktionen |
| postCreateSelf | Nach dem preCreateSelf-Schritt | Liste mit einer Reihe von durchzuführenden Aktionen |
| allowDeleteSelf | Vor dem Löschen | Boolescher Wert, der angibt, ob der Löschvorgang fortgesetzt werden kann |
| preDeleteSelf | Vor dem Löschen und vor dem Löschen aller untergeordneten dynamischen Regeln | Liste mit einer Reihe von durchzuführenden Aktionen |
| postDeleteSelf | Nach dem Löschen aller untergeordneten dynamischen Regeln, aber vor dem Löschen des Bauteils selbst | Liste mit einer Reihe von durchzuführenden Aktionen |
"Aktionen" sind Anweisungen für das automatisierte Erstellen oder Löschen von dynamischen Regeln. Nur diese Aktionen werden unterstützt.
Aktionslisten werden zum Zeitpunkt der Erstellung des Triggers erstellt. Normalerweise werden Regeln zum Erstellen von Aktionslisten verwendet. Dabei sind die meisten Elemente des Intent-Modells verfügbar. Die wesentlichen Einschränkungen sind auf die Art des Status von Intent beim Verarbeiten von Aktionen zurückzuführen. Da der Anfangstrigger eine Art von Änderung dynamischer Regeln ist, ist Intent im Begriff, dessen Status zu ändern. Da Änderungen rekursiv sein können, kann er sich in einem sehr komplizierten Status befinde und das Vorhandensein von verschiedenen dynamischen Regeln, die Änderungen unterworfen sind, ist für einen Entwickler schwierig zu erkennen.
Es ist keine "Auswerten"-Aktion vorhanden und es ist auch keine erforderlich. Wenn Sie eine Regel als Teil des Reaktors überprüfen möchten, können Sie dies tun. Dies muss jedoch kein Beitrag zur zurückgegebenen Aktionsliste sein.
Da Reaktoren die Intent-Auswertung verwenden, ist es nicht zulässig, Reaktoren innerhalb einer Auswertung auszulösen. Das bedeutet, dass es nicht zulässig ist, die Intent-API innerhalb einer Regel aufzurufen und eine dynamische Regel zu ändern, was einen Reaktor auslösen würde. Eine Ausnahme tritt auf und Sie werden feststellen, dass versucht wurde, die Auswertung erneut aufzurufen. Dies ist der Hauptgrund dafür, warum Reaktoren durch API-Aufrufe, in der Regel als Reaktion auf Benutzeroberflächenaktionen, ausgelöst werden müssen.
Aktionen lösen alle relevanten Reaktoren rekursiv aus. Es gibt keine Möglichkeit, dieses Verhalten zu unterdrücken.
Alle Aktionen in der Aktionsliste werden auf einmal verarbeitet. Nachfolgende Aktionen in der Aktionsliste haben keinen Zugriff auf die Ergebnisse von früheren Aktionen in der Aktionsliste.
Alle Aktionen in der Aktionsliste werden in einer UndoGroup als ursprünglicher Trigger ausgeführt, einschließlich aller Aktionen, die durch überlappende Ereignisse aufgerufen wurden. Wenn der Benutzer den ursprünglichen Vorgang rückgängig macht, werden somit alle vom Reaktor gesteuerten Änderungen ebenfalls rückgängig gemacht, um das Modell wieder in den ursprünglichen Zustand zurückzuversetzen. Reaktoren werden nicht ausgelöst, wenn die Vorgänge beim Rückgängigmachen oder Wiederherstellen durchgeführt werden.