Ah, that clears things up somewhat.
I can certainly start using the basic View class straight away and can
slowly start moving over to the generic class based views as time
permits and as I get more used to them.
The base View class sounds like it has all the advantages of function
based views whilst having just enough in the way of features to make it
useful.
As I said in the post I just made I'm just about to start a new website
and I'll give class based views a go with that. I'll aslo try and move
my user application over to them to see how it works.
On 03/04/2017 22:24, Andrew Pinkham wrote:
There's a little bit of vocabulary overload going on that I can't help but
point out, as it confused me when I encountered it.
There is a difference between Class-Based Views (CBV) and Generic Class-Based
Views (GCBV). They were both introduced at the same time, and so it is easy to
get them confused, but they serve very different purposes.
When referring to CBV, there is actually only a single CBV, called View. Every
other class-based view provided by Django is a generic view! The goal of these
views is to provide pre-defined, slightly-customizable behavior. The fact that
they are objects (class-based) is secondary. They are called GCBV for
historical reasons: to make a difference between the generic view _functions_
that preceded them.
As James points out, a view is simply a Python callable that receives a request
and returns a response. To that extent, the View class and function views are
_almost_ equivalent. View provides two extra things over a function view: (1)
automatic handling of the OPTIONS HTTP method and (2) denial of HTTP methods
not explicitly defined. The methods defined on subclasses of View map directly
to HTTP verbs. As developers define class methods named after HTTP methods,
View will automatically change the response returned by an OPTIONS request and
allow those methods to return data.
Of course, a function view can be implemented to handle OPTIONS and deny HTTP
methods not explicitly implemented. Django even provides a decorator for the
latter, linked below.
https://docs.djangoproject.com/en/stable/topics/http/decorators/#django.views.decorators.http.require_http_methods
My personal opinion is that language is power, and I find the terms Class-Based Views and
Generic Class-Based Views misleading. I'd prefer to simply call the latter Generic Views,
as their object nature is not their utility. In an attempt to distance the documentation
from the CBV vs GCBV, I'd consider calling View instances and subclass-instances
"Object Views". That said, when I suggested this at DjangoCon US 2015, my
suggestions seemed polarizing, so make of this what you will.
I feel pretty strongly about this topic, and gave a talk about it at the same
conference: https://www.youtube.com/watch?v=BJiOERA49ZQ
I hope this is helpful!
Andrew
http://jambonsw.com
http://django-unleashed.com
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/b17b7bb8-f33c-73fb-7054-ebed85928bfd%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
