Discussion :

[Robin56]

Bonjour,

Voici ma question MVVM du jour

Cette fois-ci ce n'est pas vraiment une erreur mais plutôt un besoin d'avis. Dans la plupart des applications WPF que j'ai découvert, la vue se binde sur des propriétés dont on connait le nom.
Mais ceci peut poser un problème car le nom de la propriété est "mise en dur" dans le fichier XAML. Il n'y a donc pas de vérification de son existence. Et, de plus, si cette propriété n'existe pas, l'application s'exécute normalement et n'affiche pas l'erreur.

Je sais que ceci permet le support de collection hétérogène par exemple mais est ce qu'il existe un moyen de vérifier l'existence de la propriété à binder.

Passer de ceci :

Code c# :

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

1
2
 
txtBlock.SetBinding(TextBlock.SetProperty, New System.Windows.Data.Binding("Title"))

A cela ??

Code c# :

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

1
2
 
txtBlock.SetBinding(TextBlock.SetProperty, New System.Windows.Data.Binding(Client.Title.ToString))

Mais je pense que ça casserait un peu le pattern.

[matdur]

Peut être avec le lien suivant

http://wekempf.spaces.live.com/blog/...71CF!694.entry

[tomlev]

Peut être avec le lien suivant

http://wekempf.spaces.live.com/blog/...71CF!694.entry

ce truc de dingue
pas mal du tout, mais je vois pas bien comment on pourrait l'exploiter en XAML...

[Thomas Lebrun]

Le pb de cette technique, c'est que tu es obligé de faire ca dans le code behind (pour pouvoir utiliser txtBlock) et dans ce cas, oui, tu casse le pattern

Bonjour,

Voici ma question MVVM du jour

Cette fois-ci ce n'est pas vraiment une erreur mais plutôt un besoin d'avis. Dans la plupart des applications WPF que j'ai découvert, la vue se binde sur des propriétés dont on connait le nom.
Mais ceci peut poser un problème car le nom de la propriété est "mise en dur" dans le fichier XAML. Il n'y a donc pas de vérification de son existence. Et, de plus, si cette propriété n'existe pas, l'application s'exécute normalement et n'affiche pas l'erreur.

Je sais que ceci permet le support de collection hétérogène par exemple mais est ce qu'il existe un moyen de vérifier l'existence de la propriété à binder.

Passer de ceci :

Code c# :

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

1
2
 
txtBlock.SetBinding(TextBlock.SetProperty, New System.Windows.Data.Binding("Title"))

A cela ??

Code c# :

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

1
2
 
txtBlock.SetBinding(TextBlock.SetProperty, New System.Windows.Data.Binding(Client.Title.ToString))

Mais je pense que ça casserait un peu le pattern.

[Robin56]

Le pb de cette technique, c'est que tu es obligé de faire ca dans le code behind (pour pouvoir utiliser txtBlock) et dans ce cas, oui, tu casse le pattern

Oui je m'en doutais bien car ça oblige à avoir un lien du ViewModel. Il n'existe donc pas de principe simple pour ce problème ? Je trouve ça bizarre qu'il y ait possibilité de faire des erreurs de binding comme celles là.

Peut être avec le lien suivant
http://wekempf.spaces.live.com/blog/...71CF!694.entry

Euh j'essaye de comprendre le mécanisme, j'avoue pas tout avoir saisis à ce lien Mais d'après ce que je vois ce mécanisme est à utiliser du coté ViewModel pour vérifier le nom des levés d'évènement. Moi ça serait plutôt du coté View. Mais il faut que je comprenne mieux la chose.

[Thomas Lebrun]

Je ne vois pas de solutions pour faire ce que tu veux: code XAML = source de pb mais code behind = plus de MVVM

[Robin56]

Ok, ouai on en arrive aux mêmes conclusion

Je trouve ça louche quand même pas de vérification du Binding mais bon. Dans de grosses applis, faut faire gaffe à toutes ces propriétés de Binding alors vu qu'on est pas alerté à la compilation ou à l'exécution.

[binoo]

Je trouve ça louche quand même pas de vérification du Binding mais bon. Dans de grosses applis, faut faire gaffe à toutes ces propriétés de Binding alors vu qu'on est pas alerté à la compilation ou à l'exécution.

Il me semble qu'il y a une trace en mode debug (F5) dans la fenêtre de sortie lorsque le binding est fait sur une propriété inexistante.

Mais c'est vrai qu'il reste des choses à améliorer pour aider le développeur.

[Robin56]

Le pb de cette technique, c'est que tu es obligé de faire ca dans le code behind (pour pouvoir utiliser txtBlock) et dans ce cas, oui, tu casse le pattern

Je reviens sur le problème juste pour bien comprendre un point.

En fait pourquoi exactement le pattern est-il cassé ?
- Car écrire le Binding dans le XAML ou dans le Behind revient au même.
- Bon devoir récupérer le DataContext pour vérifier les propriétés du ViewModel associé nécessite de récupérer le DataContext en tant que ViewModel. Donc la View nécessite de connaître des choses sur le ViewModel.

Mais en fait, un ViewModel peut servir pour plusieurs View mais pas l'inverse si ? Donc si chaque View fait référence toujours au même ViewModel, est ce qu'il y a vraiment un problème à le mentionner ?

Bon euh je sais pas si tout ceci est clair
Désolé d'insister sur ce point, j'ai juste envi de bien saisir le concept

Merci pour vos réponses

[Thomas Lebrun]

En fait, tu casses le pattern car son but est de te faire écrire le moins de choses possible dans le code behind de ta vue. Donc si tu fais ton binding par code, et ben.... c'est raté

[nemesisTHEone]

Bonjour, personelement je me suis penché sur le pattern MVVM depuis ce matin donc on peut dire que je ne suis pas vraiment calé! Mais après la lecture de quelques articles ici et là, j'ai vue dans la pluspart une réponse a ton problème.

D'après ce que j'ai compris la vue se bind au ViewModel, et c'est dans le ViewModel que le gros du code doit se faire, donc dans la plupart des codes que j'ai lue, il y a toujours une Class ViewModelBase qui implémente INotifyPropertyChanged, et dans son implémentation tu peux lire par exemple ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public void NotifyPropertyChanged(string PropertyName)
        {
 
            this.VerifyPropertyExist(PropertyName);
            if ( PropertyChanged != null )
                PropertyChanged(this, new PropertyChangedEventArgs(PropertyName));
        }
 
        [Conditional("DEBUG")]
        [DebuggerStepThrough]
        protected void VerifyPropertyExist(string PropertyName)
        {
            if (TypeDescriptor.GetProperties(this)[PropertyName] == null)
                throw new Exception("Invalid property name: " + PropertyName);
        }

Donc en mode "debug" on vérifie que la propriété existe bel et bien.

et ceci est transparent pour la vue.

j'espère que ça peut t'aider.

[Robin56]

Merci de ta réponse nemesisTHEone.

Oui effectivement le ViewModel vérifie l'existences des propriétés. J'ai comme tu l'as dis une classe ViewModelBase que chaque ViewModel implémente et donc la vérification est faite du coté des ViewModels.

En fait ce qui me pose problème, c'est le fait que les erreurs de Binding soient étouffés du coté de ta Vue.

Certes, le ViewModel vérifie l'existence de la propriété. Mais parcontre la Vue peut se Binder sur un peu tout et n'importe quoi. Si la propriété dans la Vue est erronnée (erreur de frappe, etc ...) le programme s'exécutera comme si de rien n'était (comme l'a dis binoo, il y a une petite trace dans le mode débug dans la fenêtre de sortie).

Voilà j'espère avoir été clair.