I am facing a problem of “design time support” best practices. I am using PRISM, and my objects are created by a DI container. Lets assume the following simple scenario:
I have an object workflow. This workflow has several properties, and there is a WorkflowProvider which provides a list of workflows.
If I design the ListView I do not have a problem. I am using a MainApplication object as design time data context, and my list binds to the property “WorkflowList”. In my live application I can set the data context to the appropriate implementation.
But I do not know how to handle a single workflow view!
Normally I would create a workflow object as design time data context. But my workflow object can’t be created on its own (with an empty constructor), it has to be a property of e.g. my WorkflowProvider. So one approach I used in the past was this:
- Write a dummy subclass for workflow
- In the empty constructor of the dummy, get the “real workflow”
- Assign all properties of the “real workflow” to the properties of my dummy class
- Use an instance of the dummy workflow in my design time view
The only reason for that is that I do not know how to set the design time data context to a property, instead of an object. Is this possible, or is there any other way which makes sense. To clarify, I know I could bind e.g. my grid in my “workflow details view” to a property, but then I could not use the details view without changes as a DataTemplate in my list view. I hope you got my problem 🙂
Chris
Ok,
like so often, a little bit thinking and a good guess solved my problem:
d:DataContext=”{Binding WorkflowProvider.CurrentWorkflow}”
does the trick, and will be ignored in real time scenarios…