Django - Vues basées sur les fonctions

Bien que le terme vue puisse être interprété dans un sens, dans Django Ce n'est pas le concept classique que nous utilisons pour cela, par exemple dans la programmation Web plusieurs fois le résultat qu'une vue nous donne dépend des actions de l'utilisateur, peut-être que l'utilisateur met à jour une liste déroulante et change le sens total de la vue .
Lorsque nous essayons d'établir le concept de vue, ce que nous voulons atteindre n'est pas d'essayer de le comparer au concept que nous avons peut-être prédéfini à partir d'autres environnements MVC, une fois que nous avons le concept de vue de Django nous pouvons mieux l'exprimer aux autres développeurs.
Le squelette de la vue
Si nous voyons le corps de la vue et que nous allons aux fondements de celle-ci, nous pouvons dire qu'une vue est une fonction qui prendre une requête HTTP Oui renvoie une réponse HTTP, On pourrait dire que cette approche est simple, cependant si l'on voit le but de la vue ce concept la remplit adéquatement, maintenant que pour atteindre la simplicité de ces deux éléments il faut mener d'autres activités.
Vues génériques
La philosophie de Django nous dit que nous devons tout faire pour que nos applications soient réutilisables, simples et efficaces, ce qui signifie que nous ne pouvons pas développer d'éléments répétitifs, c'est-à-dire écrire le même code encore et encore car cela n'a pas de sens, voyons l'image suivante :

Dans ce code nous voyons comment nous construisons une fonction, cette fonction nous représente une vue, cependant c'est loin d'être une solution qui répond aux points de la Philosophie Django, bien qu'il soit vrai que le code fonctionne et dans de nombreux cas il ferait le travail plus que bien, imaginons qu'au lieu de n'avoir à faire que cette vue, nous devons faire 100 ou 200 parce que nous avons une application de grandes proportions, nous devrait répéter cette logique encore et encore, générant le même type de code.
Si on regarde le nom de la vue, les paramètres qu'elle appelle, y compris la réponse qu'elle donne, qui renvoie vers une URL prédéfinie par le développeur, tout cela nous renvoie vers une vue spécifique et non générique.
Avant que nous puissions nous inquiéter, le framework a déjà une solution à ce problème et ce n'est ni plus ni moins que le vues génériques, ce sont des vues déjà définies, il suffit de joignez-leur un modèle, indiquez un modèle et nous pouvons accéder à des fonctions et des méthodes qui font toutes les bases dont nous avons besoin.
Voyons le code de ces vues génériques dans l'image suivante :

Dans l'exemple, nous pouvons remarquer plusieurs points intéressants, d'abord nous ne limitons pas la fonction à un seul modèle, nous voyons comment nous utilisons la fonction model.get_default_manager avec laquelle nous établissons quelle est la clé primaire de notre modèle, puis nous retournons le nom du modèle que nous avons obtenu en premier comme argument de la fonction.
Ici, nous n'avons plus de limitation par code, puisque cela n'est fait qu'une seule fois et l'inclut Django, nous n'avons qu'à nous soucier d'intégrer ce que nous allons utiliser, voyons l'implémentation d'une vue utilisant cette approche :

Dans notre implémentation, nous appelons simplement la fonction show_object de la classe de vues, nous indiquons quel modèle il utilisera et le nom du modèle, quelque chose de beaucoup moins répétitif et plus simple que l'approche non générique que nous avons vue au début.
Comme nous pouvons le voir, nous avons des outils dans le cadre qui nous évitent de travailler et nous pouvons également nous conformer à une philosophie de développement propre et efficace en réduisant le nombre de lignes de code inutiles que nous écrivons.Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif