La première partie va planter le décor en démarrant par vous montrer comment s’articule une application avec formulaire composé d’un sous formulaire en sus (j’expliquerai pourquoi après :)
Pour ce faire, je vous emmène dans l’univers du 7° art, viendez on va refaire StarWars!
Un modèle, un formulaire, une vue, un template et ca sera fini.
Avant, les vues génériques étaient sous forme de fonction, simples, pratiques, c’était parfait. Et ça a été retiré du framework pour des versions OO sous prétexte que c’était plus flexible.
Maintenant, ce sont ces gros tas immondes, avec un ordre d’appel de méthodes complexes, des mixins dans tous les sens et une chaine d’héritage velue.
Les Class Bbased Views se trouvent maintenant partout en Django. Je les comprends maintenant très bien, et les utilise souvent au mieux. Dernièrement j’ai du utiliser django-rest-framework, une très belle application, qui fait un usage utile et massif des CBV, et effectivement, cette architecture m’a rendu très productif.
Mais je maintiens ce que je dis depuis le début : ce n’est pas un pas en avant.
C’est léger, et ça répond à pas mal de use cases.
J’ai une préférence pour mon profile de 3-quart gauche.
Nous avons reçu plusieurs demandes d’explication des class based views et une explication de ce code dans le cadre de notre opération père castor, commente nous un snippet. Je me suis dis que j’allais faire d’une pierre deux coups et trois mouvements.
