В чем преимущество представлений на основе классов?

Сегодня я прочитал, что Django 1.3 alpha уже поставляется, и самая разрекламированная новая функция - это введение представлений на основе классов .
Я прочитал соответствующую документацию , но мне трудно увидеть большое преимущество ™ , которое я мог бы получить, используя их, поэтому я прошу здесь некоторую помощь в их понимании. .
Давайте возьмем расширенный пример из документации.

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

А теперь давайте сравним его с решением «plain-old-views», созданным мной в 5 минут на этот вопрос (прошу прощения за любую ошибку, которую вы можете найти в нем).

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))

Вторая версия мне кажется:

• Эквивалентная по функциональности
• A намного более читабельный ( self.args [0] ? ужасно!)
• Короче
• Не менее совместим с DRY

Что-то важное, что мне не хватает? Зачем мне их использовать? Это в документации? Если да, то каков идеальный вариант использования? миксины так полезны?

Заранее благодарим всех, кто вносит свой вклад!

PS для тех, кто может задаться вопросом, я никогда не был в восторге от общих представлений: как только мне понадобилось некоторые расширенные функции, они стали не короче обычных просмотров.