I want to briefly touch on the editing context and give a little introduction to its capabilities. This is part 1 of a 6 part series
The way to think about the editing context is that it is the point of contact between the hosting application, and the designer (and elements on the designer). In my PDC talk, I had the following slide which I think captures the way to think about how these elements are layered together.
The editing context represents the a common boundary between the hosting application and the designer, and the mechanism to handle interaction with the designer (outside of the most common methods that have been promoted on WorkflowDesigner). If you were to look at the implementation of some of the more common methods on WorkflowDesigner, you would see that almost all of these use the editing context in order to get anything done. For instance, the Flush method (and Save which calls Flush) will acquire an IDocumentPersistenceService from the Services collection, and then use that in order to properly serialize the document.
The EditingContext type has two important properties
The Items collection is for data that is shared between the host and the designer, or data that is available to all designers. These need to derive from ContextItem which will provide the mechanism to hook into subscription and change notification. There are a couple of interesting methods on the ContextItemManager type :
Services represent functionality that is either provided by the host for the designer to use, or is used by the designer to make functionality available to all designers within the editor. Generally, these are likely defined as interfaces, but can also be a type. It is then required for an implementation or an instance to be provided. This instance will be shared as a singleton. There are a few interesting methods on the ServiceManager type:
We’ll start walking through these over the next few posts.