Utiliser des classes pour les vues Django, est-ce Pythonic?

Question

J'apprends actuellement Python et je viens d'un solide contexte C#. Je n'arrête pas d'entendre parler de faire des choses de manière pythonique pour profiter de la nature dynamique de la langue et j'en reçois certaines et d'autres pas.

Je crée un site avec Django et mon approche des vues est d'utiliser des classes. Ma pensée actuelle est d'avoir une classe de base qui a quelques trucs sur le modèle et le modèle à utiliser. Cela aura une page de type funky 404 par défaut avec la recherche de site et d'autres choses sur la base de toutes les autres pages. Ainsi, chaque zone du site aura ses propres EG News et toutes les fonctions liées au modèle et le filtrage seront dans cette classe avec une classe supplémentaire en plus pour les requêtes HTML ou AJAX. Donc, vous auriez quelque chose comme ceci:

\ Site \ common \ ViewBase

- \ nouvelles \ NewsBase (ViewBase)

- \ nouvelles \ HtmlView (NewsBase)

- \ nouvelles \ AJAXView (NewsBase)

URL sera mis en correspondance comme http://tld/news/latest cartes à site.news.htmlview et http://tld/news//à/sera également mis en correspondance site.news.htmlview mais la classe va comprendre ce qu'il faut faire avec le paramètres supplémentaires.

C'est à peu près ce que je ferais en C# mais le tutoriel de Django ne montre que l'utilisation de méthodes pour les vues, me demandant si ce n'est pas une solution très pythonique?

Pensées?

Editer: Après un commentaire de S.Lott sur la sécurité des threads, vaut-il mieux laisser les fonctions telles quelles et les faire créer une instance d'une classe et appeler une méthode dessus?

Ce que je cherche est un endroit pour mettre un code commun pour chaque section du site pour filtrer le modèle, l'authentification pour le site, etc

Answer 1

Certes, il n'y a rien de mal à utiliser une classe pour une vue, à condition vous acheminez l'URL vers une instance réelle d'une classe et pas seulement une classe directement.

Answer 2

L'administrateur Django fait exactement cela - regardez le code source dans django/contrib/admin.

L'avantage des classes est qu'elles sont beaucoup plus faciles à personnaliser, par exemple vous pouvez ajouter des crochets pour la vérification des permissions.

Il y a une proposition pour déplacer toutes les vues génériques existantes vers les classes, il était censé entrer dans 1.2 mais n'a pas respecté la date limite. Comme l'indique l'affiche ci-dessus, faites très attention à la gestion des variables d'instance - si vous regardez les classes admin, vous voyez que la requête est passée aux différentes méthodes au lieu de s'appuyer sur "self".

Answer 3

Mis à part d'autres problèmes (tels que les problèmes de sécurité des threads), il semble qu'il y ait un réel danger possible de franchir les lignes claires entre Modèle/Vue/Modèle.

Ou peut-être que c'est comme un remplacement pour l'envoi d'URL (not that there's anything wrong with that :-). Je ne suis pas sûr, mais il se sent juste un peu hors.

Answer 4

Bien que les vues basées sur les classes soient utiles, l'héritage n'est peut-être pas le bon outil pour ce travail particulier. Les fonctions auxiliaires et les décorateurs sont deux excellents moyens d'extraire le code commun de vos opinions. Ils ont aussi tendance à être plus familier/naturel à d'autres codeurs (python) qui pourraient travailler sur votre code. Je ne sais pas quelle est la meilleure approche dans votre cas, car je ne sais pas combien vous voulez prendre en compte, mais gardez à l'esprit qu'il existe d'autres façons de prendre en compte Python en plus de l'héritage.

p.s. bravo pour chercher une solution pythonique.