Modele-vue-controleur (MVC)

Bernard PottierUniversite de Bretagne Occidentale

Bernard.Pottier@univ-brest.fr

19 avril 2009

On decrit le principe d’organisation des interfaces selon MVC. Ladescription est ici textuelle et permet de regenerer une organisationd’objet lors de l’ouverture de l’interface.Si les composants ont une identite, il est aise de les inhiber ou lesactiver de maniere a presenter une vue coherente avec l’etat de l’ap-plication.Parcels associes : IHM-Demo et MVC-Demo

1 MVC : quelques principes

MVC a ete utilise des les debuts de l’informatique interactive, largement pro-mue par l’apparition du systeme Smalltalk-80 aux laboratoires Xerox de Palo-Alto. VisualWorks s’appuie toujours largement sur cette methode de developpement,fondee sur les interactions de trois types d’objets :M le modele, ou le domaine du modele.

Ils regroupent des donnees sur lesquelles on souhaite agir, ou que l’onsouhaite presenter.

V la vue graphique.Il s’agit de representation graphiques hierarchiques s’appuyant sur un en-semble de composants tels que boutons, decors, listes, champs de saisie,editeurs. . .

C le controleur associe a la vue.C’est le mecanisme qui determine les interactions entre l’utilisateur et lemodele.Les controleurs ont une organisation hierarchique qui suit celle des vues.Ils permettent de definir la gestion d’evenements clavier ou souris dans uncadre standardise.

MVC produit des interfaces robustes et reutilisables grace a son systemehierarchique et l’abstraction des details de fonctionnement d’un niveau d’em-boitement a un autre. Les composants du Canvas sont des exemples de tripletsMVC mis a disposition des programmeurs.

1

Nous allons ici montrer quelle est la logique de cette organisation et commentproduire des composants MVC specifiques a des situations particlieres, dont lesjeux.

V1

SV2SV4 SV5

SV6

SV3

C1

C3

C4C5

C6

C2

Hierarchie descontroleurs

Hierarchie desVues

Lien structurelvue-controleur

Le curseur passe dans V2:C2 recupere le controle de C1

Fig. 1 – Structure hierarchique de MVC : chaque composant visuel est associea un controleur. Ceux-ci s’appellent mutuellement lorsque le curseur bouche,lorsque la souris clique etc. . .

La figure 1 montre une application interactive ouverte. On peut reconnaitreles contours d’une fenetre et ceux de composants qui y sont implantes. Lahierarchisation peut etre plus complexe que cette simple concatenation. Il estcourant de voir reutiliser des canvas complets a l’interieur d’autres canvas, pourles systemes de configuration, par exemple.

Lorsque la fenetre devient active, parce qu’un utilisateur y amene le poin-teur, le controleur exterieur poursuit ce pointeur. Chaque mouvement provoqueun examen de la nouvelle position par rapport aux zones occupees par les com-posants.

Si il s’avere qu’un composant est concerne par le passage du pointeur, lepassage de controle est opere, et ce composant devient actif (il prend le controle).Meme si la composition des vues d’une fenetre presente un aspect plat, il estdonc clair que le passage du controle descent et remonte dans les hierarchiesMVC.

La composition des donnees s’opere elle au travers des valueHolders par unereaction en chaine de messages qu’il s’agit de programmer.

1.1 Isolation entre interface et modele

Une application interactive comporte typiquement ces deux composantes.Une regle de conception est de separer strictement leurs roles et comporte-ments. Il est ainsi possible de prevoir et de faire evoluer les deux fonctions enindependance l’une de l’autre. Cette propriete se rencontre souvent dans les

2

applications ouvertes, les skins alternatives proposant des habillages differents,alors que les interfaces (GUI) peuvent varier pluys en profondeur.

L’outillage de VisualWorks cree les interfaces en tant que sous classe d’uneclasse abstraite ApplicationModel qui fournit tous les elements necessaires a laconstruction, l’activation et le controle des interfaces. Les interfaces utilisateurssont donc couramment des classes nommees UIXyz, heritant de ApplicationModel,et dotees de methode de classes definissant la composition de l’interface (win-dowSpec).

INTERFACE

UTILISATEUR

MODELE

Fig. 2 – Separation Interface-Modele

La figure 2 souhaite insister sur cette separation, en encourageant des developpementssepares du modele et de son, ou sesi, interfaces. L’articulation entre les deuxs’opere via des messages ou des gestionnaires de dependances garant de cetteisolation.

1.2 Terminologie

Il est malheureusement prudent de qualifier le contenu de mots rencontresdans le code, ou la documentation officielle, si ce n’est dans des textes traitantdes interfaces.

Widget : abbreviation de Window Gadget, apparue avec le systeme d’affi-chage X-Windows. Un widget designe ici un composant d’interface doted’une partie visuelle et d’un controleur optionnel. Un tel composant peutetre actif (reaction a la souris, au clavier), ou passif.Exemples : champs, etiquettes, cadres, menus, listes, tables, icones. . .

Builder : constructeur d’interface. Il interprete une specification composite(#windowSpec de Canvas) qui integre des parametres geometriques divers.Le role du Builder est de construire et peindre une fenetre (3).Il maintient egalement a jour la structure de la fenetre en gardant la listede ses composants nommes. Toutes les interventions sur ces composants

3

sont a adresser au builder : modification d’une etiquette, inhibition ouactivation d’un widget. . .Le Builder a deux modes. En mode edition, il permet de modifier unespecification dynamiquement. L’outil canvas utilise le Builder de cettemaniere.

valueHolders : instances de ValueHolder, ils assurent l’interface avec le modele.Ce sont des adaptateurs reliant le widget a l’attribut correspondant dumodele. Une modification interne ou externe du modele se repercute au-tomatiquement par un changement d’etat de l’interface.

Chaque widget comporte une vue et un controleur preferentiel. En general, ilest possible de commuter dynaiquement plusieurs controleurs sur un composant.

interface

utilisateur

Application Model

Builder

Fig. 3 – Construction de l’interface par le Builder : celui-ci ’peint’ l’interfacepour le compte de la classe ApplicationModel.

1.3 Specification et construction

La structure des resources d’une classe application peut etre aisement ins-pectee en appelant des methodes de classes telles que :UIXyz windowSpec rend la structure d’objet correspondant a l’interfaceUIXyz monMenu restitue un menu developpe defini par le selecteur #mon-

Menu dans la classe UIXyz.La figure 4 montre ainsi une inspection en profondeur realisee sur la barre de

menu de l’application UIListeDemo. Cette barre a ete developpee par un simpleappel :

UIListDemo barreDeMenu.Il est interessant de noter que tant pour les interfaces que les menus, le

processus de construction peut etre dynamique. Il est parfaitement possible degenerer des vues MVC, ou des menus, a partir de la logique de l’application.

4

Fig. 4 – Inspection en profondeur d’un menu : lire de la gauche vers la droite.

5

! UIListDemo c l a s s methodsFor : ’ r e source s ’ !

menuListe”Tools . MenuEditor new openOnClass : s e l f andSe l ec to r : #menuListe”

<r e s ou r c e : #menu>ˆ#(#{UI .Menu} #(

#(#{UI . MenuItem}#rawLabel : ’ Ajouter ’#value : #doAdd )

#(#{UI . MenuItem}#rawLabel : ’ Enlever ’#value : #doRemove )

#(#{UI . MenuItem}#rawLabel : ’ Tr ier ’#value : #doSort ) ) #(3 ) n i l ) decodeAsLitera lArray

2 Configuration dynamique et appel au Builder

2.1 Presentations contextuelles

Il est souhaitable de ne presenter aux utilisateurs que des fonctions utili-sables. Lors de l’execution d’un flot de traitements effectues par l’utilisateur(disons A, puis B, puis C), on ne presntera d’abord que A, puis A etant realise,A et B (si A peut etre refait), et enfin A, B et C.

Les menus sont egalement frequemment contextuels, ne presentant que lesoperations qui ont un sens. Par exemple si une methode a deja ete compilee avecsucces, on inhibera l’option accept tant que son code n’aura pas de nouveau etemodifie. inhibitions.png

La figure 5 esente une vue sur le browser et le menu de la fenetre de codage.On constate l’inhibition de plusieurs options qui ne sont pas realisables. Retou-chons le code et accept, ou undo redeviendront actifs. Selectionnons un mot etcopy, ou paste le seront egalement.

2.2 Operations dynamiques sur l’interface

Les composants manipules dynamiquement se voient affecter une identitedans la fenetre de configuration. On reprend ic l’exemple UIListDemo, et onaffecte l’identite (ID) #ActionBoutonPoire. Ce composant n’ayant un sens quesi l’option poire est dans la liste, il faudra l’inhiber dans le cas contraire. Lafigure 6 montre comment proceder.

6

Fig. 5 – Inhibitions dans un menu contextuel. Cet usage s’applique aussi auxcomposants d’interface : boutons, boites de saisies etc. . .

7

Fig. 6 – Il est possible d’affecter un ID aux composants pour en faciliter l’accesdynamique.

8

Cette operation etant faite, on ecrit une methode qui verifie si l’etat de laliste est compatible avec la presence du bouton de positionnement sur poire.Soit checkPoireInList : uneListe cette methode.

! UIListDemo methodsFor : ’ changing ’ !

checkPo i r e InL i s t : l i s t e

| boutonPoire |boutonPoire := s e l f bu i l d e r componentAt : #ActionButtonPoire .( l i s t e i n c l ud e s : #po i r e )

i fTrue : [ boutonPoire enable ]i f F a l s e : [ boutonPoire d i s ab l e ]

Il faut ensuite appeler cette methode a chhque operation d’insertion, sup-pression, ou rechargement de la liste, ici lors des actions commandees par lesboutons, ou le menu :

doAdd peut reajouter le symbole alors qu’il avait disparu,

doRemove peut supprimer le symbole,

doLoad peut charger une liste contenanti, ou pas, le symbole,

Ceci etant effectue, on a un interface dont les options vont s’adapter a l’etatde la liste (figure 7).

Fig. 7 – La disparition de l’option poire a provoque l’inhibition du bouton depositionnement associe.

9

3 Architecture MVC

Il est quelquefois necessaire de concevoir des interfaces specifiques, les com-posants standards ne permettant pas de representer de maniere satisfaisante lesobjets d’un modele.

Dans ces cas le programmeur doit constituer lui-meme le triplet Modele,Vue, Controleur, et l’integrer dans son application.

3.1 Organisation des classes

Il faudra donc typiquement quatre classes :

UIXyz , l’application acceuillant MVC, sous-classe de ApplicationModel, creeea partir du Canvas, a la difference des trois suivantes qui doivent etre creeesexplicitement dans le browser,

Xyz , classe supportant le modele presente, si cet objet est complexe ou a descomportements complexes,

XyzView , la vue graphique heritant de View, ou l’on dessinera une representationde Xyz,

XyzController , le controleur heritant de Controller, charge d’interpreter lesactions de l’utilisateur, en relation avec Xyz et XyzView.

Ces classes interagissent etroitement, comme la figure 9 le montre. Dans lesusages les plus courants, on observe les regles suivantes :

1. UIXyz disposera de deux variables d’instances, l’une pour referencer lemodele unXyz, l’autre pour referencer la vue une xyzVue. Le controleurpeut aussi faire partie des variables si il y a besoin de changer son com-portement.

2. la variable d’instance une xyzVue referencant la vue doit etre declaree lorsde la configuration de cette vue dans le Canvas (voir la figure 8).

3. Parce que le modele doit comporter des dependances, dont la vue qui seraffraichit a chaque changement, on l’encapsule dans un valueHolder.

4. Naturellement, il convient d’instancier la vue, le modele et le controleur,ceci s’effectuant dans la methode initialize.

5. Le modele doit etre donne a la vue, celle-ci l’utilisant lors des operations depresentation. La vue transmet ce modele automatiquement a son controleur.

6. La vue doit donc disposer d’un controleur, qu’elle cree elle-meme en ins-tanciant la classe implantee dans la methode d’instance defaultControl-lerClass, que l’on doit programmer. Alternativement, on peut creer lecontroleur dans UIXyz et l’affecter a la variable une xyzVue.

10

Fig. 8 – Installation d’une vue specifique via le Canvas. Noter que la declaration,l’initialisation, et la gestion de la variable laVue revient au programmeur.

11

Fig. 9 – Les quatre classes minimales d’un systeme MVC. La methode initializede l’application etablit les relations entre ces objets.

12

Smal l ta lk d e f i n eC l a s s : #MovingCi rc l eContro l l e rs up e r c l a s s : #{UI . Con t r o l l e r }instanceVariableNames : ’ ’c la s s Ins tanceVar iab leNames : ’ ’

Smal l ta lk d e f i n eC l a s s : #MovingCircles up e r c l a s s : #{Core . Object}instanceVariableNames : ’ c e r c l e ’c la s s Ins tanceVar iab leNames : ’ ’

Smal l ta lk d e f i n eC l a s s : #UICatchMyCircles up e r c l a s s : #{UI . Appl icat ionModel }instanceVariableNames : ’ laVue l eCont ro l eu r leModele ’c la s s Ins tanceVar iab leNames : ’ ’

Smal l ta lk d e f i n eC l a s s : #MovingCircleViewsup e r c l a s s : #{UI . View}instanceVariableNames : ’ ’c la s s Ins tanceVar iab leNames : ’ ’

! MovingCircle c l a s s methodsFor : ’ i n s t ance c rea t i on ’ !c e r c l e : c e r c l e

| mc |mc := s e l f basicNew .mc c e r c l e : c e r c l e .ˆmc ! !

3.2 Role du modele

La classe modele va etre completee de quelques methodes facilitant la mani-pulation du cerche encapsule. On va y implanter la possibilite de regenerer uneposition a l’interieur d’un rectangle englobant. Pour cela on ajoute une variablemaintenant un generateur de nombres aleatoires dont on trouvera l’usage dansla methode moveInBounds : bounds.

Notre modele est donc un cercle mobile qui peut recalculer sa position demaniere aleatoire.

Dans des situations plus complexes, le travail sur le modele demandera plusd’efforts. Ce modele peut en effet etre une structure de donnees elaborees, unensemble de valeurs collectees dans une base de donnees. Il peut etre accompagned’algorithmes requierant egalement de l’attention.

Smal l ta lk d e f i n eC l a s s : #MovingCircles up e r c l a s s : #{Core . Object}instanceVariableNames : ’ c e r c l e rand ’

13

Fig. 10 – On a ouvert un inspecteur sur l’application, puis inspecte les objetsformant le systeme MVC. On peut noter la visibilite du modele dans la vue etle controleur. Noter egalement la presence de sensor dans le controleur.

14

! MovingCircle c l a s s methodsFor : ’ i n s t ance c rea t i on ’ !c e r c l e : c e r c l e

| mc |mc := s e l f basicNew i n i t i a l i z e .mc c e r c l e : c e r c l e .ˆmc

! MovingCircle methodsFor : ’ i n i t i a l i z e −r e l e a s e ’ !i n i t i a l i z e

s e l f rand : Random new

! MovingCircle methodsFor : ’moving ’ !moveInBounds : bounds

| x y |x := ( s e l f rand next ∗ bounds width ) truncated .y := ( s e l f rand next ∗ bounds he ight ) truncated .s e l f

c e r c l e :( C i r c l e

c en te r : x @ yrad iu s : s e l f c e r c l e rad iu s )

rad iu s : numbers e l f

c e r c l e :( C i r c l e

c en te r : s e l f c e r c l e c en t e rrad iu s : number )

3.3 Role de la vue

Dans ce petit exemple, le role de la vue sera simplement de presenter lecercle a sa position. On choisit une representation pleine, obtenue en envoyantle message asFiller. Une representation creuse s’obtent respectivement avec lemessage asStroker.

Le cercle est une instance de la classe Circle, sous classe de Geometric familled’objets geometriques qui ont la capacite de se representer grace au messagedisplayOn : aGraphicContext ou le parametre est un afficheur direct ou indirect.

3.4 Role du controleur

On va simplement demander a celui-ci de repositionner le cercle lors desprises et pertes de controle. Ces moments sont aisement detectables puis quele cycle standard de Controller, dont MovingCircleController herite est unesequence :

15

! MovingCircleView methodsFor : ’ d i sp l ay ing ’ !

displayOn : aGraphicContext| c e r c l e |c e r c l e := s e l f model va lue c e r c l e .c e r c l e a s F i l l e r displayOn : aGraphicContext

Fig. 11 – Afficheur

startUp"Give control to the receiver. The default control sequence is to initialize(see Controller|controlInitialize), to loop (see Controller|controlLoop), andthen to terminate (see Controller|controlTerminate). After this sequence,control is returned to the sender of Control|startUp. The receiver’s controlsequence is used to coordinate the interaction of its view and model. In general,this consists of polling the sensor for user input, testing the input with respectto the current display of the view, and updating the model to reflect intendedchanges."

self controlInitialize.self controlLoop.self controlTerminate

Ici on va donc redefinir controlInitialize et self controlTerminate en leurdonnant un code similaire.

! Mov ingCi rc l eContro l l e r methodsFor : ’ ba s i c c on t r o l sequence ’ !

c o n t r o l I n i t i a l i z e

| bounds modele |bounds := s e l f view bounds .modele := s e l f model va lue .modele moveInBounds : bounds .s e l f model va lue : modele .s e l f view i n v a l i d a t e !

contro lTerminate

s e l f c o n t r o l I n i t i a l i z e

16

3.5 Premier role de l’application

On peut pour l’instant se desinteresser du controleur pour expliquer com-ment l’application peut maneuvrer modele et affichage.

On va supposer que la barre posee en bas de la fenetre est un reglage pourla taille du cercle.

On modifie la methode initialize pour introduire une dependance sur le va-lueHolder laGlissiere. La methode de changement utilisee est changeGlissiere.Dans cette methode on preleve la valeur de la glissiere et on donne un nouveaurayon au cercle.

changeGlissiere

| choix modele |choix := (self laGlissiere value * 20) rounded.modele := self leModele value.modele radius: choix.self leModele value: modele

Nous avons maintenant un premier systeme MVC complet et operationnel.

4 Les controleurs

4.1 Methodes heritees

Le controleur est en general demarre lorsque le pointeur entre dans la zonegraphique concernee. Une de ses variables d’instance, sensor, lui permet deprelever ou changer des objets mis a sa disposition par le systeme. Ce sontles mouvements de la souris et sa position, l’etat des touches du clavier, l’etatdes boutons de la souris.

Le cadre de programmation est la classe Controller, dont les controleursspecifiques heritent. Cette classe propose un certain nombre de methodes, quel’on re-ecrit dans un nouveau controleur. Ces methodes sont appelees automati-quement par un mecanisme de signalement d’evenements. Cette technique portele nom de “event-driven”. On peut retenir les methodes suivantes :

mouseMovedEvent : event le pointeur a bouge. On peut lire la position cou-rante en interrogeant le sensor :position := sensor cursorPointFor : event

redButtonPressedEvent : event le bouton de selection a ete enfonce,redButtonReleasedEvent : event le bouton de selection a ete relache,processKeyboardEvent : event une touche du clavier a ete enfoncee. On

peut recuperer l’etat du clavier en interrogeant sensor. Il est ensuite pos-sible d’interpreter la decision de l’utilisateur, par exemple, comme ceci :keyValue := event keyValue. (keyValue isKindOf : Character) ifTrue : [”utiliser keyValue” ]

17

4.2 Implementation d’un controleur

l s’agit d’ameliorer le controleur presente section 3. On va d’abord simple-ment se donner a traiter les clics souris, et decider si celui-ci est opere sur lecercle, ou non.

Pour cela on a besoin de traiter les evenements redButtonPressedEvent : etde connaitre la position de la souris.

Il nous suffit de deux methodes, l’une dans le controleur et l’autre dans lemodele, qui permettra de decider si le clic est positif, ou pas. Le succes estmarque par un dialogue qui l’annonce.

! Mov ingCi rc l eContro l l e r methodsFor : ’ events ’ !

redButtonPressedEvent : event| po s i t i o n c e r c l e |po s i t i o n := s e l f s en so r cursorPointFor : event .c e r c l e := s e l f model va lue .( c e r c l e i n c l ud e s : p o s i t i o n ) i fTrue : [ Dia log warn : ’Dans l a c i b l e ’ ]

! MovingCircle methodsFor : ’moving ’ !

i n c l ud e s : po int| d i s t ance |d i s t ance := point d i s t : s e l f c e r c l e c en te r .ˆ d i s t anc e <= s e l f c e r c l e rad iu s

Avec ce controleur, la cible est fixe et facile a atteindre. Essayons maintenantde la rendre mobile et furtive. Pour cela, il faut mettre en activite un processus(voir section ??) qui va periodiquement deplacer le cercle a proximite de saposition. Ce processus est implante dans une nouvelle variable d’instance dumodele MovingCircle. Il est demarre par la methode start et il est termine parterminate.

On intervient egalement dans le code du controleur pour provoquer des ra-fraichissements de la vue lors que le pointeur bouge. Si l’utilisateur ne fait rien,le cercle se deplace sans que l’utilisateur ne percoive sa position.

Avec ces modifications, et une petite taille de cercle, la cible devient delicatea attraper. On compte le nombre de clics souris, et on affiche ce nombre lorsquela cible est atteinte.

! Mov ingCi rc l eContro l l e r methodsFor : ’ events ’ !

mouseMovedEvent : event

18

| c e r c l e |c e r c l e := s e l f model va lue .s e l f model va lue : c e r c l e

redButtonPressedEvent : event| po s i t i o n c e r c l e |po s i t i o n := s e l f s en so r cursorPointFor : event .c e r c l e := s e l f model va lue .s e l f nbCl i c s : s e l f nbCl i c s + 1 .( c e r c l e i n c l ud e s : p o s i t i o n )

i fTrue :[ Dia log warn :

’Dans l a c i b l e en ’ , s e l f nbCl i c s p r i n t S t r i n g , ’ c l i c s ’ ]

! MovingCircle methodsFor : ’ c on t r o l l i n g ’ !

s t a r t| act ionBlock d e l a i |s e l f terminate . ” au cas ou un proce s su s s e r a i t a c t i f ”act ionBlock := [ [ d e l a i := Delay f o rM i l l i s e c o nd s : 200 .

d e l a i wait .s e l f moveAround : 30 ] r epeat ] . ” code du proce s su s ”

s e l f p roce s su s : act ionBlock f o rk

terminates e l f p roce s su s i s N i l i f F a l s e : [ s e l f p roce s su s terminate ]

A Suivre . . .

19

Table des matieres

1 MVC : quelques principes 11.1 Isolation entre interface et modele . . . . . . . . . . . . . . . . . 21.2 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Specification et construction . . . . . . . . . . . . . . . . . . . . . 4

2 Configuration dynamique et appel au Builder 62.1 Presentations contextuelles . . . . . . . . . . . . . . . . . . . . . 62.2 Operations dynamiques sur l’interface . . . . . . . . . . . . . . . 6

3 Architecture MVC 103.1 Organisation des classes . . . . . . . . . . . . . . . . . . . . . . . 103.2 Role du modele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Role de la vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Role du controleur . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Premier role de l’application . . . . . . . . . . . . . . . . . . . . . 17

4 Les controleurs 174.1 Methodes heritees . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Implementation d’un controleur . . . . . . . . . . . . . . . . . . . 18

20