Points de vue de classe dans Django

Django des points de vue pour une fonction, qui peut être un problème si vous souhaitez modifier uniquement un peu de fonctionnalité. Oui, je pourrais avoir des millions de mots clés arguments et encore plus si les déclarations dans la fonction, mais je pensais plus à une approche orientée objet.

Par exemple, j'ai une page qui affiche un utilisateur. Cette page est très similaire à la page qui affiche un groupe, mais c'est quand même pas si similaire à seulement utiliser un autre modèle de données. Le groupe a également des membres, etc...

Un autre moyen serait de point de vue pour les méthodes de la classe, puis d'étendre cette classe. Quelqu'un a déjà essayé cette approche ou a une autre idée?

InformationsquelleAutor Seb | 2008-08-03
  1. 42

    J'ai créé et utilisé mon propre générique classes de vue, la définition de __call__ donc une instance de la classe est appelable. Je l'aime beaucoup; alors que Django générique de vue de permettre un certain degré de personnalisation par le biais de mots clés arguments, OO générique de vue (si leur comportement est divisé en un certain nombre de méthodes distinctes) peut avoir beaucoup plus fine de personnalisation via le sous-classement, ce qui me permet de me répéter beaucoup moins. (Je suis fatigué de la réécriture du même créer/mettre à jour la logique de vue chaque fois que j'ai besoin de modifier quelque chose Django générique de points de vue ne sont pas tout à fait le permettent).

    J'ai posté un peu de code à djangosnippets.org.

    Le seul véritable inconvénient que je vois est la prolifération de l'intérieur les appels de méthode, qui peut avoir un impact quelque peu les performances. Je ne pense pas que ce est beaucoup plus d'une préoccupation; il est rare que Python exécution de code serait votre goulot d'étranglement des performances dans une application web.

    Mise à JOUR: Django propre générique vues sont maintenant basées sur la classe.

    Mise à JOUR: FWIW, j'ai changé d'avis sur la classe de base des points de vue depuis cette réponse a été écrit. Après avoir utilisé de manière intensive sur un couple de projets, je pense qu'ils ont tendance à conduire à un code qui est plaisant à SEC à écrire, mais très dur à lire et à maintenir plus tard, parce que la fonctionnalité est répartie dans de nombreux endroits différents, et les sous-classes sont tellement dépendants sur chaque détail de l'implémentation de la super-classes et de mixin. J'ai maintenant le sentiment que TemplateResponse et afficher des décorateurs est une meilleure réponse pour la décomposition afficher le code.

    • Python exécution n'est pas LE goulot d'étranglement, mais pourrait affecter le site de l'évolutivité, et de l'ensemble de la performance. Je suis tellement contente de memcache existe!
    InformationsquelleAutor Carl Meyer
  2. 13

    J'avais besoin d'utiliser la classe de base point de vue, mais je voulais être en mesure d'utiliser le nom complet de la classe dans mon URLconf sans toujours avoir à instancier la classe de la vue avant de l'utiliser. Ce qui m'a aidé était étonnamment simple métaclasse:

    class CallableViewClass(type):
    def __call__(cls, *args, **kwargs):
        if args and isinstance(args[0], HttpRequest):
            instance = super(CallableViewClass, cls).__call__()
            return instance.__call__(*args, **kwargs)
        else:
            instance = super(CallableViewClass, cls).__call__(*args, **kwargs)
            return instance


class View(object):
    __metaclass__ = CallableViewClass

    def __call__(self, request, *args, **kwargs):
        if hasattr(self, request.method):
            handler = getattr(self, request.method)
            if hasattr(handler, '__call__'):
                return handler(request, *args, **kwargs)
        return HttpResponseBadRequest('Method Not Allowed', status=405)

    Je peux maintenant deux instancier les classes d'affichage et d'utiliser les instances comme les fonctions d'affichage, OU je peux simplement mon point de URLconf de ma classe et ont la métaclasse instancier (et appel) le point de vue de classe pour moi. Cela fonctionne en vérifiant le premier argument de __call__ – si c'est une HttpRequest, il doit être un réel requête HTTP, car il serait absurde de tentative d'instancier une classe d'affichage avec un HttpRequest instance.

    class MyView(View):
    def __init__(self, arg=None):
        self.arg = arg
    def GET(request):
        return HttpResponse(self.arg or 'no args provided')

@login_required
class MyOtherView(View):
    def POST(request):
        pass

# And all the following work as expected.
urlpatterns = patterns(''
    url(r'^myview1$', 'myapp.views.MyView', name='myview1'),
    url(r'^myview2$', myapp.views.MyView, name='myview2'),
    url(r'^myview3$', myapp.views.MyView('foobar'), name='myview3'),
    url(r'^myotherview$', 'myapp.views.MyOtherView', name='otherview'),
)

    (J'ai posté un extrait de ce à http://djangosnippets.org/snippets/2041/)

    • littéralement génial
    InformationsquelleAutor Erik Allik
  3. 10

    Si vous êtes tout simplement de l'affichage de données à partir de modèles, pourquoi ne pas utiliser le Django Générique Vues? Ils sont conçus pour vous permettre de facilement afficher les données à partir d'un modèle sans avoir à écrire votre propre point de vue et des trucs sur le mappage d'URL paramètres de points de vue, de l'extraction de données, la manipulation bord des cas, le rendu de la sortie, etc.

    InformationsquelleAutor rossp
  4. 3

    Vous pouvez toujours créer une classe, remplacer la __call__ fonction, puis pointer l'URL du fichier à une instance de la classe. Vous pouvez prendre un coup d'oeil à la FormWizard classe pour voir comment c'est fait.

    • Le balisage processeur mangé votre __s'. Utiliser \_ cacher le balisage. La classe __appel__ méthode est appelée. La question est de s'assurer que le urls.py a une instance de la classe à sa disposition. Il rend votre urls.py un peu plus compliqué.
    InformationsquelleAutor dguaraglia
  5. 2

    Me semble que vous êtes en essayant de combiner les choses qui ne devraient pas être combinées. Si vous avez besoin de faire différents types de traitement de votre point de vue en fonction de si c'est un Utilisateur ou un Groupe d'objet que vous essayez de regarder, alors vous devriez utiliser deux différentes fonctions d'affichage.

    D'autre part, il peut être des expressions communes que vous souhaitez extraire de votre object_detail type de points de vue... peut-être que vous pourriez utiliser un décorateur ou tout simplement des fonctions d'assistance?

    -Dan

    InformationsquelleAutor
  6. 2

    Sauf si vous voulez faire quelque chose d'un peu plus complexes, en utilisant le générique de vues sont le chemin à parcourir. Ils sont bien plus puissants que leur nom l'indique, et si vous êtes juste de l'affichage des données du modèle générique de vue faire le travail.

    InformationsquelleAutor Harley Holcombe
  7. 1

    Générique vues sera généralement la voie à suivre, mais en fin de compte, vous êtes libre de gérer les Url si vous voulez. FormWizard fait des choses dans une classe de base, de même que certaines applications RESTful Api.

    Essentiellement avec une URL, vous êtes donné un tas de variables et de la place pour fournir un callable, ce appelable vous fournir est complètement à vous - à la norme est de fournir une fonction - mais en fin de compte Django met pas de restrictions sur ce que vous faites.

    Je suis d'accord que quelques exemples de la façon de le faire serait de bon, FormWizard est probablement l'endroit où commencer.

    InformationsquelleAutor Andrew Ingram
  8. 1

    Si vous souhaitez partager des fonctionnalités communes entre les pages, je vous suggère de regarder les étiquettes personnalisées. Ils sont tout à fait facile à créer, et sont très puissants.

    Aussi, les modèles peuvent s'étendre à partir d'autres modèles. Cela vous permet d'avoir un modèle de base pour définir la mise en page de la page et à partager entre les autres modèles de remplir les blancs. Vous pouvez imbriquer des modèles pour toute profondeur; vous permettant de spécifier la mise en page sur différents groupes de pages dans un seul endroit.

    • Je ne pense pas mettre trop de logique dans le modèle est une bonne idée.
    InformationsquelleAutor Andrew Wilkinson
  9. 1

    Vous pouvez utiliser le Django Générique point de Vue. Vous pouvez facilement atteindre les objectifs souhaités de la fonctionnalité complète de Django générique Vues

    InformationsquelleAutor Varun Chadha