CODEWITHSUNDEEP
wpfmvvmcaliburn.microdatatrigger
heltonbiker
heltonbiker

Reputation: 27595

How to apply convention-over-configuration with Caliburn.Micro instead of these DataTriggers?

I have a View/ViewModel pair properly working with Caliburn.Micro.

Inside the view, there is a ContentControl whose content is bound to the same viewmodel, and depending on the value of a given enumerated property in the viewmodel, I want a different template for the ContentControl:

<ContentControl Content="{Binding}">
    <ContentControl.Resources>
        <DataTemplate x:Key="TurnedOffView">
            <local:TurnedOffView/>
        </DataTemplate>
        <DataTemplate x:Key="DeviceReadyView">
            <local:DeviceReadyView/>
        </DataTemplate>
    </ContentControl.Resources>
    <ContentControl.Style>
        <Style TargetType="ContentControl">
            <Setter Property="ContentTemplate" Value="{StaticResource TurnedOffView}"/>
            <Style.Triggers>
                <DataTrigger Binding="{Binding State}" Value="{x:Static local:DeviceStates.Ready}">
                    <Setter Property="ContentTemplate" Value="{StaticResource DeviceReadyView}"/>
                </DataTrigger>
                <!-- More DataTriggers here, one for each state -->
            </Style.Triggers>
        </Style>
    </ContentControl.Style>
</ContentControl>

I know Caliburn.Micro can use cal:View.Model and cal:View.Context so that multiple views can be bound to each ViewModel, but I can't figure out how to use this to avoid all this verbosity.

So the question is:

How should I use View.Model and View.Context (and rename my views) in this scenario to take advantage of Caliburn.Micro convention-over-configuration approach?

Upvotes: 0

Views: 307

Answers (1)

mvermef
mvermef

Reputation: 3914

<ContentControl cm:View.Model="{Binding}" cm:View.Context="{Binding ContextProp, Mode=TwoWay}" /> might be something to try... Then your context would be based off code in your viewmodel not having to structure datatemplates with view-first code. ContextProp would be basically a sub view of your view in question (based on namespace Project.Views.MainView.Main.TurnedOff) ContextProp = "TurnedOff";

yea sorry.. Its how I see the folder structure (namespaces)... So instead of TurnedOffView it could be TurnedOff.xaml under a folder named Main. This was assuming your primary view is MainView.xaml and your primary Viewmodel is MainViewModel.cs. SOrry for the confusion.

View.Model can be setup to do multiple viewmodels, at that rate you might want to think about Conductor in the framework. But I don't think it would be warranted since you are basically doing view switching in the presented case above.

Upvotes: 1

Related Questions