|
Action Models in depth |
  
|
|
Action Models in depth |
|
Recall from section 1 that the IAction.Path property is known as the action path, and that action models are specified implicitly through action paths: for a given set of actions, the framework constructs an action model by considering the Path property of each action in the set.
However, it is important to note that this is not a deterministic operation. For example, consider the following set of actions and associated paths:
S = {
a : “global-menus/File/Open”,
b: “global-menus/File/Close”,
c: “global-menus/Help/About”
}
The following model can be produced from S:
However, the following model can also be produced from S:
In other words, the ordering of the nodes in the action model tree is significant (because it directly affects the appearance of menus and toolbars in the user-interface), and yet this ordering is not specified by the set S (assuming S is an unordered set). In order to deterministically construct an action model, an external ordering constraint must be provided.
The ClearCanvas framework allows this ordering to be provided via an external model specification in the form of an XML document. The ActionModelRoot.CreateModel(…) method takes 3 parameters: a model namespace, an action site, and a set of actions. The namespace and site together uniquely identify a model specification.
For a given set of actions S, and a model specification M, the following algorithm is applied:
| 1. | When CreateModel(M, S) is called, the framework looks for the model specification M. If M does not exist, it is created as an empty model specification. |
| 2. | The actions in S are inserted into the model tree in the order specified by M. |
| 3. | Any actions in S that were not specified by M are inserted into the model tree, either based on its GroupHint, or at the end if no GroupHint is provided. These actions are also added to the specification M. |
The first time CreateModel(M, S) is called for a given M, M will not exist, but will be created. Since M does not specify anything, all actions in S will simply be inserted into M according to the GroupHint rules, although the actual order of insertion is in an arbitrary order.
The next time CreateModel(M, S) is called, M will exist, and the actions in S will be inserted into the model tree in the order specified by M. If S grows (because new tools that contribute new actions are added to the system), the new items in S are inserted into M according to the GroupHint rules, hence M grows along with S.
In addition to specifying the order in which actions are inserted into the model, M may be used to override the action paths that are initially specified by the actions themselves. Hence M can be used to completely re-organize the action model if desired.