Re: Will function based views ever be deprecated?

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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.