Events and Handlers

Events for Simple Rules

<ruleName>_allowModify? Event occurs prior to the modification of a dynamic rule. The handler is a Boolean method that specifies whether the modification is to be allowed or not. If it returns True, then the modification proceeds. If it returns False, then the modification is cancelled.

<ruleName>_preModify Event that happens prior to the modification. The handler can see the previous value of <ruleName>. The handler is a method that returns a list of actions to be performed.

<ruleName>_postModify Event that happens just after the modification. The handler can see the previous value of <ruleName>. The handler is a method that returns a list of actions to be performed.

<ruleName>_allowDelete? Event occurs prior to the deletion of a dynamic or modifiable rule. The handler is a Boolean method that specifies whether the deletion is to be allowed or not. If it returns True, then the deletion proceeds. If it returns False, then the deletion is cancelled.

<ruleName>_preDelete Event that happens just prior to the deletion. If the rule was a Child rule, this event happens prior to the 'deleteSelf' events. The handler can see the current value of <ruleName>. The handler is a method that returns a list of actions to be performed.

<ruleName>_postDelete Event that happens just after the deletion. If the rule was a Child rule, this event happens after all of the 'deleteSelf' events. The handler can not access the value of <ruleName>, unless the deletion exposes an underlying 'default' design-rule. The handler is a method that returns a list of actions to be performed.

Events for Child Rules

The following events and their handlers are used to indicate when dynamic parts are added and deleted. These handlers are normally coded as "design rules" in the design of the part that is being added or deleted.

preCreateSelf Event happens just after the part is created. Obviously the part has to be created in order for its event-handler to run! The handler is a method that returns a list of actions to be performed.

postCreateSelf Event happens after preCreateSelf event. The handler is a method that returns a list of actions to be performed.

allowDeleteSelf? The handler is a Boolean method. If it returns False, then the child is not deleted, nor are any of the modifications underneath, if any. If the deletion is disallowed, no error or other notification happens to the caller — it appears to the caller as if the deletion succeeded, but in fact the part is still there.

preDeleteSelf Event happens just before the child-rule is deleted, and prior to the deletion of any dynamic/modified rules underneath the child. The handler is a method that returns a list of actions to be performed.

postDeleteSelf Event happens after all dynamic/modified rules underneath this child have been deleted, and just before the rule is deleted. So the child is still there, but stripped of all lower level dynamic rules. The handler is a method that returns a list of actions to be performed.

Actions

“Actions” are the behaviors that you can specify “to happen” when the event is triggered. These are the only actions that you can have happen.

Each action is specified as a list in "plist format" (alternating names and values). The first field (name) is always action, followed by one of the following:

• CreateDynamicRule creates an "Any" type rule, on any part, with any name, with any formula. Required fields are: part which specifies the parent (owner) of the new rule, name which is the name of the new rule and must be an Intent Name, and formula which is the formula for the new rule. The formula must be a string, even if it's a simple constant such as a number.
• CreateDynamicPart creates a Child rule. Required fields are: part which specifies the parent (owner) of the new rule, name which is the name of the new rule and must be an Intent Name. Following those required fields are the parameters and formulas of the new child rule, including the 'design' pseudo-parameter. The parameters must be Names. But the formulas, of course, are strings.
• DeleteDynamicRule deletes any dynamic rule (or dynamic “modifying” rule). Required fields are: part which specifies the parent (owner) of the rule to be deleted, and name which is the name of the rule to be deleted. Note that if the deleted rule is a child rule, all dynamic/modified rules underneath will also be deleted, and any relevant event handlers will be recursively fired.
• There is no "evaluate" action, and none is required, in most cases. If you want to evaluate a rule as part of your handler, just do it. It just doesn't contribute to the returned actionlist. Perhaps we will add it in the future, just in case you need to evaluate something only after some of your actions have taken place.
• Others. In the future, it is likely that there will be other actions, e.g., "importModel".

Important Notes

Actions will recursively trigger any relevant events. There is currently no way to turn this off.

All the actions in the action-list are computed at once. Subsequent actions in the action-list cannot access the results of earlier actions in the action-list.

All the actions in the action-list take place within the same undo-group as the original triggering event, including any actions invoked by cascading events. This implies that if the user “undoes” the original operation, all the event-handler-controlled changes will also be undone, in order to bring the model back to the original state. Events are not triggered when the operations happen as part of undo-ing or redo-ing.

Errors that occur during the evaluation (creation) of the action-list, or during the processing of the action list (‘part’ is not a Part, name of rule is not a Name, etc.) are silently swallowed. This makes them very difficult to debug! Work on your event-handler rules slowly and carefully to be sure that they’re really right.