Django pour ZdS : CBV ou pas CBV ?

Salut les devs,

L'autre jour il me semble avoir vu passer des messages du genre "oui, on va bientôt passer toutes nos vues en CBV, ça va être cool".

Sauf que je suis tombé là-dessus tout à l'heure :

• http://sametmax.com/des-annees-plus-tards-je-naime-toujours-pas-les-cbv/
• http://sametmax.com/je-nexpliquerai-plus-les-cbv/

Du coup, on peut en discuter ?

Le premier liens laisse penser que c'est indispensable pour Django Rest Framework et que c'est d'ailleurs un des bon cas d'utilisation. Du coup, puisque c'est une dépendance de l'API, a t'on le choix ? D'autant que le deuxième liens dit :

Je ne les ai jamais aimées. 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.

Ce qui sous entend que c'est (maintenant) la façon de faire standard de Django.

Du coup, qu'on aime ou pas, ça a l'air inhérent à Django donc a moins de changer de framework…

ps: je suis loin d'etre un pro de Django, je fais juste une analyse rapide des articles

Mon avis sur la question : les CBV sont plutôt sympa, et pratiques pour factoriser du code qui se retrouve de partout sinon (aller chercher un formulaire si on est en GET, le valider si on est en POST, récupérer la liste de tous les forums, …).

Par contre, elles ont en effet un arbre d'héritage un poil immonde, et il faut savoir quelle méthode surcharger pour faire les bons trucs. Ce ne sont pas des points qui m'ont gênés jusqu'à aujourd’hui, dans mes (petits) projets perso.

D'autre part, je pense que l'utilisation des CBV est très bien dès lors que l'on reste sur un schéma classique, avec plein de relations en base de données SQL. Dès lors que l'on passe à des trucs basés plutôt sur des documents et du NoSQL, les CBV (et Django) montrent leurs limites.

Enfin, dans les articles ci-dessus, Sam ne dis pas que les CBV c'est le mal, il dit qu'elles sont complexe à appréhender par les débutants, ce qui n'est pas la même chose.

Déjà les function based views sont dépréciées par Django, donc on a pas le choix que de passer a du CBV de toute façon.

Cependant, beaucoup de personne s'accordent à dire que cette depréciation est une erreur, car le modèle CVB a tendance à complexifier pas mal une application. En fait, le modèle CBV n'est pas adapté à pour les débutants, mais permet au code d'être plus robuste et maintenable. Ce n'est donc pas forcément une mauvaise chose. On aura juste un peu plus de mal à obtenir des contributeurs au code, mais a coté de ça on gagnera en stabilité. Et de toute façon on a pas le choix, à un moment django va arrêter le support des Function Based Views.

C'est quand même dommage, parce que du coup, Django a récupéré un des inconvénients du monde JEE qui est la complexité d'entrée dans un projet. Cependant, il faut l'avouer, l'héritage multiple dans le dev web (même en Java on ne fait pas ça), c'est quand même atroce comme pratique.

Attention, c'est les function-based views génériques qui semblent être dépréciées. Ou alors Django est complètement incohérent avec lui-même, parce qu'on trouve encore des function-based views (non génériques) dans leurs tutos, sur les versions récentes.

Je ne suis pas un pro de django, MAIS, j'aime vraiment les CBV (et je vais vraiment écrire ce tuto pour zds du coup :p).

Je pense que pour le coup je suis un cas particulier mais pour moi c'était impossible de s'y retrouver dans vos vues fonctions. D'une part le nommage est catastrophique mais en plus entre le if request.GET puis elif request.POST et la redondance énorme de code que ça génère, il m'a fallu un petit moment pour être vraiment opérationnel sur le code de zds.

Il faudra ajouter que j'ai un background web assez ancien et "autodidact" je pars du tuto php de m@téo, j'ai fait du code igniter avec le tuto officiel, j'ai fait du Symfony avec le tuto de winzo, puis je suis allé sur ASP.NET MVC avec seulement mes dix doigts et sans tuto.

Et avec les CBV, je me retrouve plus ou moins avec les CBV de ASP.NET, en presque mieux.

Presque parce que la gestion des décorateur est catastrophique.
Presque parce qu'à forcer la "généricité", on a oublié le cas non négligeable dans le web qui est celui du contenu principal (DetailView) suivi de la liste de ses commentaires (ListView).

My bad ça m'apprendra à lire de travers. Mais du coup comme l'a dit Kje, le fait qu'on utilise DRF nous "force" quelque peu à faire du CBV.

[HS] Mon Django commence à être un peu rouillé, mais si tu as les modèles

1
2
3
4
5

class Article(models.Model):
     pass

class Comment(model.Model):
     article = models.ForeignKey(Article, related_name="comments")

Normalement, dans tes templates tu peut faire :

1
2
3

{% for comment in article.comments %}
    {{comment.render_to_html}}
{% endfor %}

[/HS]

En fait, je comprends tout à fait les questions de SpaceFox quant à l'adoption des CBV. Quand je lis le premier article :

Je trouve ces points très pertinents. Je ne suis pas un expert Django (tellement loin de l'être) mais j'apprends plutôt rapidement, je vais régulièrement lire la documentation et je passe 50% de mon temps dans le code source des vues génériques (<3 PyCharm).

Alors oui, contrairement aux vues génériques de DRF qui sont vraiment bien foutues, les vues génériques Django sont vraiment pénibles à utiliser. Alors pourquoi opter pour cette approche ? Parce que les fonctions ne permettent pas d'adopter une architecture convenable.

A l'époque (et toujours aujourd'hui mais nous y travaillons), nous avions une très grosse répétition de code. Il aurait été possible de réduire cette répétition de code par composition mais cela aurait été bien moins naturel que les solutions que nous utilisons à ce jour (utilisation de mixins et d'autres approches orientés plus Django). Certes, il y a des désavantages mais il y a aussi des avantages que tes articles ne citent pas. Je ne connais pas "Sam et Max" mais j'aimerais d'autres sources qui valident leurs propos (du bon et du mauvais côté).

Concernant l'"obligation" de développer en CBV avec DRF, je ne pense pas que c'est le cas. DRF propose des vues CBV ou non (de simples fonctions) et ces vues ne sont pas bien différentes des vues Django au final.

OK, ce que je lis surtout c'est que les avantages et inconvénients des CBV sont connus, et que ça n'a pas été choisi "parce que c'est hype de faire comme ça" (argument beaucoup trop souvent cité, avec son petit frère "on a toujours fait comme ça"). Ce qui me rassure vraiment sur la pertinence du choix.

Normalement, dans tes templates tu peut faire :

Je ne parlais pas des templates, ça c'est facilement gérable, je parle de la généricité. Dans un monde merveilleux, une liste est paginée. D'ailleurs la ListView propose une pagination par défaut. Que ZDS a étendue d'ailleurs pour mettre "le dernier message de la page précédente".

Dans un monde merveilleux, une page avec un contenu particulier est identifiée par sa clef primaire donc il suffit de connaître le modèle dudit contenu et pas besoin de tout recoder.

Mais vois-tu l'attribut model_class est le même dans ListView et DetailView donc impossible d'utiliser la double généricité. Il faut soit recoder la partie "DetailView" soit la partie "ListView".

J'ai pas lu les réactions (rapide coup d'œil entre deux épreuves) mais je vais réagir à l'article de S&M (que je viens de lire également). Je trouve que cet article montre que la fonctionnalité est trop méconnue de l'auteur de l'article. Le CBV permet de faire des choses que l'on ne peut faire sans. C'est également une simplification quand on à des tonnes de fois un bout de code en commun.

Pour avoir passé 2 ans sans connaître le CBV et l'avoir découvert après ça a juste changé ma vie. J'ai gagné en temps, en lisibilité, en efficacité.

Le premier article de SF cite entre autre un article de Nick Coghlan qui dit sensiblement la même chose : C'est bien mais que les FBV ne devraient pas être déprécié pour autant parce que les CBV ce n'est pas bon pour tout. Alors que Sam et Max sont surtout connu dans la sphère française pour leur vulgarisation (dans tous les sens du terme) de Python, Nick Coghlan ce n'est pas n'importe quiil est un des gros core-developer de Python, il fait partit du Board of Directors de la PSF rt responsable en gros de tout ce qui a trait aux package dans le monde Python (si vous aimez ou pas pip, c'est lui qu'il faut aller voir).

Pour autant de tout ce que j'en lit, c'est que les CBV sont bien et utiles pour pas mal de choses mais peuvent être considérés plus compliqué qu'elles ne pourraient l'etre. Sam et Max ne semblent pas dire qu'il ne faut pas l'utiliser mais que c'est compliqué pour un débutant et que ce n'est pas idéal pour tout.

Comme le fait remarquer Spacefox, manifestement, c'est un choix qui a été réfléchit et c'est donc probablement pertinent d'utiliser ça.