Essai de conception et d'implémentation d'une plateforme web d'aide à l'orientation des étudiants dans leurs recherches de travaux de fin de cycle

III.2.4. FONCTIONNEMENT DE DJANGO : LE MODELE MVC/MVT

Le Model-View-Controller (MVC pour les intimes)

La plupart de Framework, offrant une interface graphique, utilisent ce qu'on appelle « architecture MVC ». Le MVC ou design pattern, est un modèle de développement utilisé par plusieurs Framework web. Il consiste en la séparation des tâches à effectuer selon les différentes couches de développement.

Le « MVC » est donc décomposé en trois couches :

- Modèle : le modèle représente une information stockée quelque part, dans une base de données ou simplement dans un fichier comme c'est le cas de SQLite.

- Vue : la vue est la présentation de cette information à l'utilisateur. Il s'agit donc de ce que l'utilisateur voit, quelles actions effectue-il sur l'interface ?

- Contrôleur : il prend en charge tout évènement de l'utilisateur comme une requête, interroge le modèle et puis se charge de renvoyer le résultat à la vue correspondante afin que l'utilisateur aperçoive le résultat.

Pour bien comprendre la logique MVC, il suffit de se représenter un cas simple : une simple recherche sur le site de Google, par exemple. L'utilisateur tape au clavier l'adresse www.Google.com. En fait, il s'agit d'une requête utilisant le protocole http que le navigateur installé sur la machine (appelé Client) envoi au contrôleur. A ce moment, le contrôleur se charge d'aller chercher la page d'accueil (vue) correspondante dans la base de données (modèle) de Google. S'il la trouve, il la renvoi immédiatement au client. Celui-ci voit alors s'afficher la page d'accueil de Google sur son écran.

Django et son Model-View-Template (MVT ou MTV)

Django, fidèle à son esprit innovateur n'a pas apprécié la philosophie MVC et a préféré créer son propre modèle ; l'architecture MVT. Le truc c'est que dans les faits, il n'y a pas vraiment beaucoup des différences entre le MVT et le MVC.

En effet, Django s'est seulement approprier la partie « Controller ». Django est donc le contrôleur dans l'architecture MVT. Pour les développeurs de Django, la vue ne représente pas la présentation des données affichées. En d'autres termes, elle s'occupe des données à affichées et non de quelle façon les affichées.

Ainsi, avec Django ; la vue est simplement une fonction Python appellée par une adresse URL particulière. Alors que la présentation ou affichage concrète se fait dans une couche à part appelé « template ». Ainsi, le contenu est séparé de la présentation.

Donc, Django sera considéré comme un Framework MVT ou MTV :

- Modèle : le modèle décrit la structure de données (base de données, etc.) ;

- Vue : la vue contrôle ce que l'utilisateur voit ;

- Template : s'occupe de la présentation de l'information.

Figure 22. Fonctionnement du Framework MVT(LORENT, op.cit.)

Un template est aussi appelé « gabarit ». Il s'agit simplement d'un fichier Html que la vue récupérera avant de l'envoyer à l'utilisateur par le truchement de Django.

On en revient donc au modèle MVT. Le développeur se doit de fournir le modèle, la vue et le template. Une fois cela fait, il suffit juste d'assigner la vue à une URL précise, et la page est accessible. Si le template est un fichier HTML classique, un modèle en revanche sera écrit sous la forme d'une classe où chaque attribut de celle-ci correspondra à un champ dans la base de données. Django se chargera ensuite de créer la table correspondante dans la base de données, et de faire la liaison entre la base de données et les objets de votre classe. Non seulement il n'y a plus besoin d'écrire de requêtes pour interagir avec la base de données, mais en plus le Framework propose la représentation de chaque entrée de la table sous forme d'une instance de la classe qui a été écrite. Il suffit donc d'accéder aux attributs de la classe pour accéder aux éléments dans la table et pouvoir les modifier, ce qui est très pratique !

Projet VS Application

Pour finir, parlons un tout petit peu de cette spécificité intéressante de Django.

Un projet est diffèrent d'une application. En fait, lorsque vous concevez un site web avec Django, vous êtes en train de concevoir un projet Django. Un projet peut être constitué d'une ou des plusieurs applications.

Une application Django est un ensemble des fichiers des codes Python, Django, Css, etc. qui sont obligatoirement subdivisés de telle sorte que chacun puisse avoir un rôle relatif à un aspect de l'architecture MVT.

Concrètement, vous concevez un blog avec Django. Votre blog constitue du point de vue de Django, un projet. Maintenant, pour avoir un blog, on suppose qu'on aura besoin des articles de publication, des adresses des utilisateurs, des galeries photos, etc.

Dans ce contexte, les articles, adresses, galeries constituent des applications de votre projet blog. Ainsi donc, vous aurez une application `articles'qui contiendra un modèle (la base de données contenant vos articles), un fichier pour vos vues, un ou plusieurs templates (fichiers Html, Python, css, etc.) et ainsi de suite.

Voyez l'avantage ce qu'une application bien réalisée peut être utilisée dans un autre projet simplement et sans causer des problèmes. Si un ami veut réaliser un projet de média en ligne, par exemple. Il aura besoin des articles comme pour notre projet de blog et d'autres applications aussi.

Si notre application `articles' tourne merveilleusement bien, il peut très bien nous l'emprunter et la réutiliser comme telle en l'intégrant simplement dans son projet. C'est la force de Django.