Programmation d'IHM avec les Morph
From OFSET Wiki
Beaucoup d'applications nécessitent le développement d'Interfaces Homme-Machine (IHM) pour la saisie des données ou leur visualisation. C'est pour beaucoup de développeurs, une tâche peu intéressante. Elle est souvent longue mais constitue souvent le point d'entrée pour vos applications et il est nécessaire de les soigner pour ne pas rebuter vos précieux futurs utilisateurs.
Cette documentation a pour objectif de présenter comment construire des IHM basiques. Il s'agit des plus ennuyeuses à développer, mais quelle application n'a pas besoin d'un champ de saisie, d'une liste déroulante ou d'une zone de texte correctement gérée ?
[edit] Pré-requis
Pour bien comprendre cette documentation, il faut avoir pratiqué un minimum Smalltalk (avec Squeak par exemple) : vous savez ce qu'est une classe, une méthode, un envoi de message...
On parle aussi de modèle et de vue. Ces termes ont un sens bien précis, regardez les principes fondamentaux du MVC ( model-view-controller). Un bon point d'entrée : [1]. Le principe fondamental sous-jacent du MVC est qu'on doit le plus possible séparer le code métier (les classes qui constituent le modèle) du code mis en oeuvre pour la présentation ou pour l'interface utilisateur.
Pour résumer :
- le terme modèle désigne les classes métiers, celles qui constituent réellement la plus-value de votre code. C'est votre super compilateur, les classes de votre système d'information (i.e. Client-Article-Facture-Bilan) ou les classes qui mettent en oeuvre la logique de votre jeu.
- le terme vue désigne les classes interfaces, présentées à l'utilisateur et qui lui permettent d'intervenir sur le modèle sous jacent. C'est le browser de code pour votre compilateur, les champs de saisie, les listes déroulantes et les labels de votre système d'information.
La modification des données est sous la responsabilité des classes du modèle. Les vues ne font que présenter les informations et ne modifient jamais directement les données du modèle. La vue et le modèle sont séparés : le modèle ne fait pas directement référence aux classes de la vue. Concrètement, les classes du modèle ne contiennent pas de variable d'instance qui référence une instance d'une classe de la vue. Ces principes bien appliqués assurent le découplage entre la vue et le modèle.
Et le contrôleur dans tout ça ?
Le contrôleur gère les interactions entre l'utilisateur et la vue. On peut dire pour simplifier que ce sont des classes qu'on utilise sans en avoir vraiment conscience. Avec les widgets disponibles, les branchements sont déjà effectués, ça marche tout seul !
[edit] Tutoriel
Les premiers chapitres de cette documentation présentent les principaux Morphs utilisés pour construire des IHM. Pour ce faire, une application exemple (un éditeur de texte) est développée de bout en bout. Voici l'export squeak du code des différentes versions de l'application exemple : MUIDoc.st.
Les questions relatives à la gestion des fichiers sous squeak ne sont pas spécifiquement expliquées dans cette documentation. Pour plus de précisions sur ce point, lisez la FAQ.
L'IHM des premières versions est simple, mais l'application est déjà fonctionnelle. Les chapitres suivants sont construits comme un tutoriel qui vous montre comment construire cette application. Tout d'abord la fenêtre, avec sa couleur, ses dimensions, son menu. Ensuite, ce qu'il faut pour le texte, la zone d'édition, le label et le champ de saisie pour le nom du fichier édité. Sans oublier les notions importantes de modèle et de vue qui sont introduites. On ajoute une barre de boutons est voilà.
