¿Cuál es la ventaja de puntos de vista basados ??en la clase?

Question

He leído hoy que Django 1.3 alpha es el transporte marítimo, y la nueva característica más promocionado es la introducción de puntos de vista basados ??en la clase .
He leído las correspondiente documentación , pero me resulta difícil ver el gran ventaja ™ que podría conseguir mediante el uso de ellos, por lo que estoy pidiendo aquí un poco de ayuda en la comprensión de ellos.
Tomemos un ejemplo avanzado de la documentación.

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

Y ahora vamos a comparar a una solución “llanura de edad-puntos de vista”, hecho por mí mismo en 5 minutos para este tema (Me disculpo por cualquier error que pueda encontrar en ella).

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 segunda versión me parece:

• El equivalente en funcionalidad
• Mucho más legible (self.args[0]? Horrible!)
• Shorter
• No menos SECO negativos

¿Hay algo grande que me falta? ¿Por qué debo utilizar? Son los de la documentación? Si es así, ¿cuál sería el caso de uso ideal? Son mixins que tiene utilidad?

Gracias de antemano a cualquier persona que contribuye!

P.S para aquellos que se preguntan, nunca fui cautivado por las vistas genéricas, así:. Tan pronto como yo necesitaba algunas funciones avanzadas, que se convirtió en no más corto que vistas regulares

.

Answer 1

Puede subclase una clase y métodos refine como get_context_data para casos específicos, y dejar el resto como está. No se puede hacer eso con funciones.

Por ejemplo, puede que tenga que crear una nueva vista que hace todo una anterior hace, pero hay que incluir la variable adicional en el contexto. Subclase el punto de vista original y reemplazar el método get_context_data.

Además, la separación de los pasos necesarios para hacer que la plantilla en métodos separados promueve código más claro - al menos hecho en un método, más fácil es de comprender. Con funciones de vista regulares, todo se vuelca en la unidad de un solo proceso.

Answer 2

Si self.args[0] le está molestando, la alternativa es:

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

A continuación, se podría utilizar self.kwargs['slug'] lugar, por lo que es un poco más fácil de leer.

Answer 3

La función de su ejemplo y de clase no son iguales en características.

La versión basada en la clase proporciona la paginación de forma gratuita y no permita el uso de otros verbos HTTP GET que.

Si desea agregar esto a su función, que va a ser mucho más largo.

Pero es, de hecho, más complicado.

Answer 4

Esta es la primera vez que escucho de esto - y me gusta mucho.

La ventaja que veo aquí, la verdad, es que hace más consistente con vistas Django en general. Los modelos son clases y siempre he sentido que deben ser vistas también. Sé que no todo es más que puntos de vista y modelos son los dos muy usado tipo .

En cuanto a la ventaja técnica? allí, así es realmente una diferencia - Bueno, en Python todo es una clase ( u objeto ?)? ¿No es el azúcar sintáctico 99% en el primer lugar?

Answer 5

Una manera de pensar acerca de las vistas a base de clase, es que son como una la administración de Django con las ruedas de entrenamiento fuera y por lo tanto mucho más flexible (pero más difícil de entender).

Por ejemplo, la lista de visualización en el admin se basa claramente en el ListView genérico. La vista de lista simple que sólo sería definir un modelo o conjunto de consultas.

class MyExampleView(ListView);
    model = ExampleModel 

Usted tendrá que proporcionar su propia plantilla, pero básicamente será el mismo que el ModelAdmin más básico. El atributo list_display en el modelo de administración que le dirá qué campos mostrar, mientras que en el ListView que haría esto en la plantilla.

class SpeciesAdmin(admin.ModelAdmin):
    list_display = ['name']
admin.site.register(ExampleModel , ExampleModelAdmin)

Con el administrador tiene un parámetro

list_per_page = 100

que define el número de objetos por página. Ver lista tiene

paginate_by = 100

que logra la misma cosa. Del mismo modo, si usted mira en la personalización de la administración en gran medida, verá una gran cantidad de solapamiento.

Este sitio aquí debe darle una mejor idea de lo que hacen así.

http://ccbv.co.uk/