Discussion :

[Falcor]

Salut à tous, je m'experimente actuellement au pattern MVC et je viens demander conseil sur un problème que je rencontre.
Voici un exemple simple pour expliquer la chose.

Le modèle est une simple classe Number qui représente un nombre et qui possède une méthode "incrémenter et décrémenter".

La vue est un simple label représentant le nombre de la classe Number ainsi qu'un bouton incrémenter et décrémenter.

Ce que je veux mettre en oeuvre dans le controleur, c'est que la valeur du nombre ne peut pas dépasser 10. Si on essaye de dépasser cette valeur, un label d'erreur s'affiche sur la vue indiquant à l'utilisateur qu'il ne peut plus incrémenter le nombre. Par contre dès qu'on décrémente le nombre et donc qu'il prend une valeur inférieure à 10 je veux que le message d'erreur ne s'affiche plus.

Pour ce faire il faudrait gérer l'état de la fenêtre via un pattern state ou tout simplement via un booléen "erreur" qui indique si la vue doit afficher le message d'erreur ou pas.

Est-ce la bonne manière de procéder (utiliser une variable d'état ) ?
Et surtout, faut-il que je gère l'état au niveau de la vue ou du controlleur ? Je pense qu'il faut faire ça au niveau du controlleur, mais je trouve celà un peu lourd...

Qu'en pensez vous ? Est-il fréquent de devoir gérer l'état d'une vue via un controlleur ? Comment implémentez vous celà ?

[bilred]

Bonjour

• ou tu renvoie un booléen de la méthode du controlleur qui alerte si la demande s'est rélisée ou pas, et la vue affiche ce qu'il faut en fonction de ce code d'erreur qu'elle récupère (seule la vue qui a tenté de modifier sera au courant)
• ou bien tu met plusieurs méthodes de mise à jour pour les vues dans le modèle avec leur correspondant différents dans la vue et tu appele l'une ou l'autre en fonction du succès des mises à jours. Toutes le vues seront alertées. Le state pattern m'a l'air un peu exessif dans la cas présent.
• Une variable d'état est tout à fait potable, sauf qu'un moment il faut la réinitialiser, et ce moment est assez délicat à choisir pour minimiser les conflits.
  (accès à la variable par une vue alerté pour une oprétion d'erreur après un accès à cette même variable par une vue alertée par une opération conforme et exécuté juste après l'opération interdite... c'est possible avec des threads.)

Poff, siNon En général quand la valeur entrée est contrôlée et qu'il à été décidé qu'elle n'était pas valide, il suffit de balancer une exception de type runtime(enfin un type héritant et propre à cette situation de préférence) qui va remonter jusqu'à la vue et sera catchée la bas.

Bien sur c'est plus lourd coté machine, mais c'est le plus pertinent et pratique coté utilisation (assurance que la logique associée à l'action s'interrompt, remontée jusqu'à la vue pour prévenir l'utilisateur de l'utilisation d'une valeur invalide,ou jusqu'au main et donc crash, ce qui fait qu'on ne peut pas oublier de la gérer)
.....
Cordialement
bilred