|
Summary of today’s design meeting 1. Controlling which actions appear in the desktop user-interface It was decided that the desktop will always display actions
according to the following equation: Visible actions = desktop global actions + active workspace
actions where -desktop global actions are derived
from the set of tools that extend ClearCanvas.Desktop.DesktopToolExtensionPoint -active workspace actions is a set
of actions obtained from the IWorkspace.Actions (or similarly named) property The ApplicationComponentHostWorkspace implementation of
IWorkspace simply delegates this property to IApplicationComponent.Actions. The important point here is that the hosted component has
complete control over the set of actions that it returns, and hence the set of
actions that it contributes to the user-interface. ApplicationComponentHostWorkspace can only host a single
application component. Any scenario requiring multiple components to be
shown in the same workspace will require the development of a root “container”
component to host the child components and manage the interaction between
them. It is then the responsibility of this container component to
determine the set of actions that the workspace exposes to the UI. 2. Tools are singletons Previously certain tools (those that extended DesktopToolExtensionPoint)
were singleton while other tools were instantiated on a per-workspace
basis. In order to simplify conceptually the framework object-model, all
tools will now be instantiated as singletons, regardless of what extension
point they extend, and the context on which the tool operates will be allowed
to vary. This changes the dynamics of the interaction between tools
and their contexts and has several implications: -
previously, the ITool.SetContext()
method was only ever called once, at the beginning of the tool’s
lifetime. Now, a tool must be designed to expect this method to be called
numerous times throughout its lifetime, as the application context changes
(e.g. the active workspace changes, etc.) -
tools must be stateless with respect
to their context. That is, a tool must not cache context-specific (or
workspace-specific) state information in member variables, because the context
may change. Instead, tools will be able to store context-specific
mementos and history via the context interface. -Jonathan |
_______________________________________________ dev mailing list [email protected] http://clearcanvas.ca/mailman/listinfo/dev_clearcanvas.ca
