Discussion :

[zapho]

Bonjour,

Je rencontre un problème de création de combobox WPF "hybride" : celle-ci doit contenir une série de TextBlock définis à partir d'une source de données (ça, c'est bon, cf. code ci-dessous) mais également un bouton (ou un item capable d'émettre une commande).

Précision, le cadre de développement est MVVM donc pas de code-behind possible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<ComboBox ItemsSource="{Binding Source={StaticResource AircraftTypeSources}}" Grid.Column="1" Grid.Row="2" Margin="5">
                <ComboBox.ItemTemplate>
                    <DataTemplate>
                        <TextBlock Text="{Binding Path=Name}" />
                    </DataTemplate>
                </ComboBox.ItemTemplate>
                <ComboBox.SelectedItem>
                    <Binding Path="AircraftType" UpdateSourceTrigger="PropertyChanged" Mode="TwoWay" />
                </ComboBox.SelectedItem>
            </ComboBox>

Quelqu'un aurait-il une idée ?

Merci.

[Thomas Lebrun]

Modifie le template de ta Combo pour y ajouter un Button et en dessus, tu met l'ItemsPresenter. Comme ca, tes items ont leur template et ta combo a aussi un bouton

[tomlev]

Précision, le cadre de développement est MVVM donc pas de code-behind possible.

Il n'est pas interdit d'utiliser du code-behind en MVVM... ce qu'il ne faut pas, c'est mettre de la logique métier dans le code-behind. Mais si c'est purement lié à l'interface graphique, il n'y a pas vraiment de contre-indication, même si beaucoup de gens (moi y compris) préfèrent l'éviter

[Thomas Lebrun]

Il n'est pas interdit d'utiliser du code-behind en MVVM...

En effet, le principe du MVVM, c'est de mettre le moins de code behind possible mais parfois, on est obligé...

[tomlev]

En effet, le principe du MVVM, c'est de mettre le moins de code behind possible

Ben c'est même pas vraiment ça, du moins comme je le vois... le principe c'est de séparer la vue du modèle, et le ViewModel sert d'adapteur entre les deux. Ce qui ne concerne strictement que la vue a tout à fait sa place dans le code-behind.

Enfin bon, je me fais l'avocat du diable, vu que comme je l'ai dit je n'aime pas non plus utiliser de code-behind . Dans la plupart des cas il y a moyen de se débrouiller avec des propriétés attachées, qui seront réutilisables ailleurs...

Mais bon, c'est très intéressant cette discussion philosophique sur les tenants et les aboutissants de MVVM, mais on s'écarte un peu du sujet (d'ailleurs c'est moi qui ai commencé, désolé )

[zapho]

Tout d'abord, merci pour vos réponses.

Je commence avec WPF et MVVM et j'aime la testabilité qui vient avec ce pattern. Après, pour le code-behind ma première impression c'est que c'est très pratique et potentiellement dangereux pour la testabilité. Enfin bref, je crois que l'on est d'accord

Pour en revenir à ma question d'origine, j'ai encore un peu de mal avec les Data Template, les ItemsPresenter, etc. Auriez-vous un exemple de code ou un lien ?

[tomlev]

Je commence avec WPF et MVVM et j'aime la testabilité qui vient avec ce pattern. Après, pour le code-behind ma première impression c'est que c'est très pratique et potentiellement dangereux pour la testabilité. Enfin bref, je crois que l'on est d'accord

Ben ce qui est testable, c'est le ViewModel, pas la vue. Donc si tu mets du code spécifique à la vue dans le code-behind, il ne sera effectivement pas testable, mais de toutes façons ce n'est pas ça que tu cherches à tester...

Pour en revenir à ma question d'origine, j'ai encore un peu de mal avec les Data Template, les ItemsPresenter, etc. Auriez-vous un exemple de code ou un lien ?

Le plus simple c'est que tu utilises un outil du genre ShowMeTheTemplate pour regarder le template par défaut d'un ComboBox (Blend doit pouvoir le faire aussi, mais comme je ne l'utilise pas je ne suis pas sûr...), et que tu modifies comme ça t'arrange. En l'occurrence il faudrait ajouter le bouton au même niveau que le ItemsControl