Как применить стандартную конфигурацию с Caliburn.Micro вместо этих DataTrigger?

У меня есть пара View / ViewModel, которая правильно работает с Caliburn.Micro.

Внутри представления есть ContentControl, содержимое которого привязано к той же модели представления, и в зависимости от значения данного перечисляемого свойства в модели представления мне нужен другой шаблон для 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>

Я знаю, что Caliburn.Micro может использовать cal:View.Model и cal:View.Context, чтобы несколько представлений могли быть привязаны к каждой ViewModel, но я не могу понять, как это использовать, чтобы избежать всей этой многословности.

Итак, вопрос:

Как мне использовать View.Model и View.Context (и переименовать свои представления) в этом сценарии, чтобы воспользоваться преимуществом подхода Caliburn.Micro, основанного на предпочтении конфигурации?


person heltonbiker    schedule 03.11.2014    source источник
comment
‹ContentControl cm: View.Model = {Binding} cm: View.Context = {Binding ContextProp, Mode = TwoWay} /› может быть чем-то, что можно попробовать ... Тогда ваш контекст будет основан на коде в вашей модели просмотра, не требующем структурирования Таблицы данных с кодом просмотра. ContextProp будет в основном подвидом вашего рассматриваемого представления (на основе пространства имен Project.Views.MainView.Main.TurnedOff) ContextProp = TurnedOff;   -  person mvermef    schedule 04.11.2014
comment
Я все путаюсь: где в Project.Views.MainView.Main.TurnedOff заканчивается пространство имен и начинается имя класса? Каким должно быть мое полное имя класса для TurnedOff View?   -  person heltonbiker    schedule 04.11.2014
comment
@mvermef Спасибо, думаю, теперь я понял, попробую завтра. А пока, если вы захотите опубликовать это в качестве ответа, я с радостью приму его, если он сработает (кроме того, эта информация либо отсутствует, либо очень скрыта, потому что я не нашел ее в документации).   -  person heltonbiker    schedule 04.11.2014


Ответы (1)


<ContentControl cm:View.Model="{Binding}" cm:View.Context="{Binding ContextProp, Mode=TwoWay}" /> может быть чем-то, что стоит попробовать ... Тогда ваш контекст будет основан на коде в вашей модели просмотра, и вам не нужно будет структурировать таблицы данных с помощью кода, ориентированного на просмотр. ContextProp будет в основном подвидом вашего рассматриваемого представления (на основе пространства имен Project.Views.MainView.Main.TurnedOff) ContextProp = "TurnedOff";


да, извините .. Вот как я вижу структуру папок (пространства имен) ... Итак, вместо TurnedOffView это может быть TurnedOff.xaml в папке с именем Main. Предполагалось, что ваше основное представление - MainView.xaml, а ваша основная модель представления - MainViewModel.cs. Извините за путаницу.

View.Model может быть настроен для работы с несколькими моделями просмотра, при этом вы можете подумать о Conductor во фреймворке. Но я не думаю, что это будет оправдано, поскольку в представленном выше случае вы в основном выполняете переключение вида.

person mvermef    schedule 04.11.2014