81 votes

Quel est l’avantage de vues basés sur une classe ?

J'ai lu aujourd'hui que Django 1.3 alpha est l'expédition, et la plupart des vanté nouveauté est l'introduction de la classe de base des points de vue.
J'ai lu la documentation pertinente, mais j'ai du mal à voir le gros avantage™ que je pourrais obtenir de l'aide, donc je pose la question ici pour de l'aide dans la compréhension.
Prenons un exemple avancé de la documentation.

urls.py

from books.views import PublisherBookListView

urlpatterns = patterns('',
    (r'^books/(\w+)/$', PublisherBookListView.as_view()),
)

views.py

from django.shortcuts import get_object_or_404
from django.views.generic import ListView
from books.models import Book, Publisher

class PublisherBookListView(ListView):

    context_object_name = "book_list"
    template_name = "books/books_by_publisher.html",

    def get_queryset(self):
        self.publisher = get_object_or_404(Publisher, name__iexact=self.args[0])
        return Book.objects.filter(publisher=self.publisher)

    def get_context_data(self, **kwargs):
        # Call the base implementation first to get a context
        context = super(PublisherBookListView, self).get_context_data(**kwargs)
        # Add in the publisher
        context['publisher'] = self.publisher
        return context

Et maintenant, nous allons la comparer à un "bon vieil points de vue" de la solution, faite par moi-même en 5 minutes pour cette question (je m'excuse pour toute erreur que vous pouvez trouver en elle).

urls.py

urlpatterns = patterns('books.views',
    url(r'^books/(\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

views.py

from django.shortcuts import get_object_or_404
from books.models import Book, Publisher

def publisher_books_list(request, publisher_name):
    publisher = get_object_or_404(Publisher, name__iexact=publisher_name)
    book_list = Book.objects.filter(publisher=publisher)

    return render_to_response('books/books_by_publisher.html', {
        "book_list": book_list,
        "publisher": publisher,
    }, context_instance=RequestContext(request))

La deuxième version me semble:

  • L'équivalent dans la fonctionnalité
  • Beaucoup plus lisible (self.args[0]? terrible!)
  • Plus courte
  • Pas moins SECS compatible

Est-il quelque chose de grand, je suis absent? Pourquoi devrais-je utiliser? Sont celles de la documentation? Si oui, alors ce serait l'idéal en cas d'utilisation? Sont mixin qui est utile?

Merci d'avance à toute personne qui contribue!

P. S. pour ceux qui pourraient se demander, je n'ai jamais été fasciné par les génériques point de vue ainsi: dès que j'ai besoin de quelques fonctionnalités avancées, ils sont devenus plus courte que les points de vue.

48voto

Evan Porter Points 2128

Vous pouvez sous-classe d'une classe et d'affiner les méthodes comme get_context_data pour des cas spécifiques, et de laisser le reste tel quel. Vous ne pouvez pas le faire avec des fonctions.

Par exemple, vous pourriez avoir besoin pour créer un nouveau point de vue qui fait tout à la précédente, mais vous devez inclure variable supplémentaire dans le contexte. Sous-classe de la vue d'origine et remplacer la get_context_data méthode.

Aussi, en séparant les étapes nécessaires pour rendre le modèle en différentes méthodes favorise le code plus clair - du moins fait dans une méthode, plus il est facile à comprendre. Régulièrement les fonctions d'affichage, c'est tout l'objet de dumping dans une unité de traitement.

17voto

Alex Points 151

Si `` est vous tracasse, l’alternative est :

Alors vous pourriez utiliser `` au lieu de cela, ce qui en fait un peu plus lisible.

10voto

e-satis Points 146299

Votre exemple de fonction et de la classe ne sont pas égaux en fonctionnalités.

La version de classe de base fournissent la pagination gratuite et interdisent l’utilisation d’autres verbes HTTP que GET.

Si vous souhaitez ajouter à votre fonction, il va être beaucoup plus longue.

Mais il est bien plus compliqué.

4voto

Frank V Points 9690

C'est la première fois que j'entends cela, et je l'aime.

L'avantage que je vois ici, honnêtement, c'est qu'il rend la vue plus cohérente avec Django globale. Les modèles sont des classes et j'ai toujours senti que les points de vue devraient l'être aussi. Je sais que tout n'est pas mais les points de vue et les modèles sont les deux largement utilisés types.

Comme pour l'avantage technique? Eh bien, en Python, tout est une classe (ou d'un objet?) -- est-il vraiment une différence? N'est-il pas 99% de syntaxe de sucre en premier lieu?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X