Ce n’est pas un secret que nous n’aimons pas trop les CBV sur ce blog. Pourtant des tas de gens continuent de les utiliser car avoir des vues sous forme de classe leur permet plus de réutilisabilité.
Ce n’est pourtant pas nécessaire.
On vous a déjà dit qu’une vue Django n’était qu’une fonction ordinaire, qui prenait en paramètre une requête, et retournait une réponse.
On ne vous a pas tout dit.
En fait Django accepte n’importe quel callable comme vue, pas juste une fonction. Et Python permet de réagir à l’appel de n’importe quel objet grâce à la méthode __call__.
Du coup:
class MaVue(object): def __call__(self, request): # mettre ici le code de la vue # comme si c'était une vue foncton ma_vue = MaVue() |
Puis dans urls.py:
url('/', 'ma_vue') |
Marche parfaitement.
Et vous pouvez hériter de MaVue, faire des mixins, et tout le toutim. Sans avoir à ajouter de la complexité, comme si c’était une vue fonction normale.
Il y a juste un truc à savoir: tout ce qu’on met dans self.attribut est partagé entre toutes les instances. Donc sur ce type de vue sous forme de classe, on évite de stocker un truc dans self, on fait des méthodes de classes auxquelles on passe des paramètres.
Sinon on évite juste d’utiliser les vues sous forme de classe. on vit très bien sans.
Bonjour,
je rebondi sur ce sujet avec une question somme toute surement “QQ la praline”, mais est-ce que le fait de ne pas utiliser les CBV, à terme, ne risque pas de voir son code déprécié ? par exemple là avec django-profiles j’ai ces warning dans les logs
/usr/local/lib/python2.6/dist-packages/django/views/generic/simple.py:8: DeprecationWarning: Function-based generic views have been deprecated; use class-based views instead.
DeprecationWarning
/usr/local/lib/python2.6/dist-packages/django/views/generic/list_detail.py:10: DeprecationWarning: Function-based generic views have been deprecated; use class-based views instead.
DeprecationWarning
Qu’en penser ?
Oui, on risque d’avoir son code déprécié. Je pense néanmoins que les fontions génériques seront toujours entretenus pas la communauté comme une app à part, car la demande est très forte.
Putain, mais ils sont cons chez Django!!
Deg, je commencais à me mettre à l’aise avec le framework, et maintenant, je vais devoir recommencer à zéro avec leurs €#€?$ de CBV où il faut faire 10 lignes de codes pour récuperer une variable d’URL!!!
Et apparemment, tout le monde s’en plaint, mais il n’en ont rien à foutre, ils déprécient quand même les FBV!!!!
On passe d’un truc simplissime à une espèce d’usine à gaz, genre framework java.
Désolé, y’a un abruti qui m’a saoulé ce matin au boulot, je suis pas spécialement calme (ni objectif).
@Syl
te plains pas, mois sam m’a fait commencer direct en CBV, la torture ultime avant de me dire qu’un fonction pouvait faire aussi bien l’affaire :)
@Max: Ah le salaud! ;)
N’empêche, je trouve que ça en fout vraiment un coup à l’intérêt de Django…tout devient tellement compliqué!
Comme le disait Sam dans un article, pour quelqu’un qui connait le framework, c’est chiant, mais pas insurmontable, mais pour un p’tit nouveau, je serais pas surpris qu’il décide de passer à pyramids ou un autre framework!
J’hésite à tout recoder avec des CBV, ne sachant pas jusqu’à quand ça va tourner en FBV. D’ailleurs, sur les docs officiels de Django, dans le tuto “Write your 1st application”, ils utilisent toujours les FBV…
Bref, moi qui suis encore relativement novice dans Django, je sais pas dans quelle voie me tourner!
Là, j’en suis à essayer de comprendre comment appeler un ModelForm dans une CBV.
En fait, ce sont les FBV génériques qui sautent, on peut toujours écrire des vues sous forme de fonction à la main.
C’est d’ailleurs ce que les core des de Django font eux même :
– vue générique => CBV
– vue custom => fonction
Trop la claaaasse!!!!!
Merci pour l’info, tu m’évite pas mal de boulot là!