difference between class based view and function based view

[Gear Crew]

what is difference between class based view and function based view and
which I choose to build full website

[TimT Vogt]

You build webapps with functions
And functions You combine in classes
So the function can be re used Inside your application

Verstuurd vanaf mijn iPhone

what is difference between class based view and function based view and which I choose to build full website
--
You received this message because you are subscribed to the Google Groups "Django users" group.
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/5d823971-6ccc-4b44-a830-9ba96d477d5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andréas Kühne]

That was really not that helpful.

Classed Based Views (CBV) use a lot of defaults for populating your
templates, forms and views. You can inherit and extend CBV's to add the
functionality that you require. You could have a base class that uses all
of the same default functionality and then just adds different templates
depending on which view should be used. You could also add other
functionality depending on what is required for a certain url.

You also can group the different methods used for a view in one class - and
disallow what you don't want.

A function based view is only one function that then renders the template -
however you cannot overload and add functionality in other parts.

See here :
https://simpleisbetterthancomplex.com/article/2017/03/21/class-based-views-vs-function-based-views.html

I think the CBV's are really good for adding and overloading functionality
and prefer them - however I know that people who have used Django for a
long time prefer Function Based Views.

Regards,

Andréas

Post by TimT Vogt
You build webapps with functions
And functions You combine in classes
So the function can be re used Inside your application
Verstuurd vanaf mijn iPhone
what is difference between class based view and function based view and
which I choose to build full website
--
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
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/5d823971-6ccc-4b44-a830-9ba96d477d5b%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/5d823971-6ccc-4b44-a830-9ba96d477d5b%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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
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/2F8CE8C2-D5E2-409D-9FD3-50DEDE259383%40gmail.com
<https://groups.google.com/d/msgid/django-users/2F8CE8C2-D5E2-409D-9FD3-50DEDE259383%40gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Andrew Pinkham]

Django developers talk about three kinds of views:

- function views (FV)
- class-based views (CBV)
- generic class-based views (GCBV)

People do not make always make the difference between CBV and GCBV, which is unfortunate, as they serve different purposes (naming things is hard). When Andréas states earlier in this thread that "(CBV) use a lot of defaults for populating your templates, forms and views" that is not 100% precise. He means GCBV---which provide default (generic) behavior---not CBV.

Let's break it down. Below is an example of a FV.

from django.http import HttpResponse
from django.views.decorators.http import (
require_http_methods
)

# below is equivalent to require_safe decorator
@require_http_methods(["GET", "HEAD"])
def hello_world(request):
"""Demonstrate HTTP Request/Response"""
return HttpResponse("Hello World")

Below is an example of an equivalent CBV.

from django.http import HttpResponse
from django.views import View

class HelloWorld(View):
"""Demonstrate HTTP Request/Response"""

def get(self, request):
"""Handle GET HTTP method"""
return HttpResponse("Hello World")

Formally, a CBV is any class that inherits from View. The only difference between the two views above is that the View class being inherited will give you automatic handling of HTTP OPTIONS.

Stated otherwise: FV and CBV are *equivalent* with the exception of automatic OPTIONS handling in CBV.

GCBV are simply CBV that have been given behavior. For example, instead of programming a view that shows a template with model data, you can instead inherit a DetailView, and customize it by setting class variables and by overriding methods. For more about that, I recommend looking at https://ccbv.co.uk .

So, when should you use a FV, CBV, or GCBV?

If you are building a view that a GCBV provides behavior for, save yourself time and use it! It's easy to add or slightly modify GCBV behavior, but difficult to remove behavior. The moment you're thinking about removing something a GCBV does, stick to a function or CBV.

So then, for choosing between FV or CBV: Do you need to handle multiple HTTP methods? Is there shared behavior between how the resource is handled by those HTTP methods? If yes, a CBV can help organize that logic and avoid duplicate code.

However, if you have a simple view (typically only one or two HTTP methods must be handled), then a FV will serve you fine (remember the view decorators!).

If you're not sure, start with a FV, and then switch to a CBV or GCBV if appropriate (as complexity goes up or when you realize you can use a GCBV).

Hope that helps,
Andrew
https://jambonsw.com
https://django-unleashed.com

[Andréas Kühne]

Great write up! :-)

And you are totally right - I tend to think of the CBV's and GCBV's in the
same thought - and use them interchangeably, because I NEVER use FV....

Regards

Andréas

Post by Andrew Pinkham
- function views (FV)
- class-based views (CBV)
- generic class-based views (GCBV)
People do not make always make the difference between CBV and GCBV, which
is unfortunate, as they serve different purposes (naming things is hard).
When Andréas states earlier in this thread that "(CBV) use a lot of
defaults for populating your templates, forms and views" that is not 100%
precise. He means GCBV---which provide default (generic) behavior---not CBV.
Let's break it down. Below is an example of a FV.
from django.http import HttpResponse
from django.views.decorators.http import (
require_http_methods
)
# below is equivalent to require_safe decorator
@require_http_methods(["GET", "HEAD"])
"""Demonstrate HTTP Request/Response"""
return HttpResponse("Hello World")
Below is an example of an equivalent CBV.
from django.http import HttpResponse
from django.views import View
"""Demonstrate HTTP Request/Response"""
"""Handle GET HTTP method"""
return HttpResponse("Hello World")
Formally, a CBV is any class that inherits from View. The only difference
between the two views above is that the View class being inherited will
give you automatic handling of HTTP OPTIONS.
Stated otherwise: FV and CBV are *equivalent* with the exception of
automatic OPTIONS handling in CBV.
GCBV are simply CBV that have been given behavior. For example, instead of
programming a view that shows a template with model data, you can instead
inherit a DetailView, and customize it by setting class variables and by
overriding methods. For more about that, I recommend looking at
https://ccbv.co.uk .
So, when should you use a FV, CBV, or GCBV?
If you are building a view that a GCBV provides behavior for, save
yourself time and use it! It's easy to add or slightly modify GCBV
behavior, but difficult to remove behavior. The moment you're thinking
about removing something a GCBV does, stick to a function or CBV.
So then, for choosing between FV or CBV: Do you need to handle multiple
HTTP methods? Is there shared behavior between how the resource is handled
by those HTTP methods? If yes, a CBV can help organize that logic and avoid
duplicate code.
However, if you have a simple view (typically only one or two HTTP methods
must be handled), then a FV will serve you fine (remember the view
decorators!).
If you're not sure, start with a FV, and then switch to a CBV or GCBV if
appropriate (as complexity goes up or when you realize you can use a GCBV).
Hope that helps,
Andrew
https://jambonsw.com
https://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
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/C2853144-5CA1-4FAD-ACDF-C487AE8CE47E%40andrewsforge.com
.
For more options, visit https://groups.google.com/d/optout.

[Carsten Fuchs]

Hi Andrew,

many thanks for your clear and detailed explanation!

Having used Django for several years, FVs are still my favorite approach
over CBVs and GCBVs. In the past, I made several starts with CBVs, but
never found or understood why CBVs and GCBVs seem to be in many people's
center of attention.

FVs are not only the most simple of the three, but they also have the
virtue of emphasizing the basic generic HTML web functionality and the
way how forms work: The three logical paths that form processing can
take are clearly shown in e.g. this (modified) example from
https://django-book.readthedocs.io/en/latest/chapter07.html

def contact(request):
if request.method == 'POST':
form = ContactForm(request.POST)
if form.is_valid():
# success, now use form.cleaned_data
return HttpResponseRedirect('/contact/thanks/')
else:
form = ContactForm()

# We get here both for GET requests and POST requests
# with invalid forms.
return render(request, 'contact_form.html', {'form': form})

When I was new to Django (and in fact new to serious web development),
understanding this concept, as step by step explained in the above
mentioned chapter, was one of the key insights for me.

CBV and GCBV obscure this imho fundamental concept. Personally, I've
never found the CBV's help with DRY outweigh the clarity of FVs. With
all the attention and efforts that are spent on making getting started
with Django easier for beginners, I was really surprised when even the
official Django tutorials were changed from FVs to CBVs.

I write this email to thank you for your explanation, but also to add
the above thoughts, which I have long been pondering but never found a
place to write down. ;-)

Best regards,
Carsten

Post by Andrew Pinkham
- function views (FV)
- class-based views (CBV)
- generic class-based views (GCBV)
People do not make always make the difference between CBV and GCBV, which is unfortunate, as they serve different purposes (naming things is hard). When Andréas states earlier in this thread that "(CBV) use a lot of defaults for populating your templates, forms and views" that is not 100% precise. He means GCBV---which provide default (generic) behavior---not CBV.
Let's break it down. Below is an example of a FV.
from django.http import HttpResponse
from django.views.decorators.http import (
require_http_methods
)
# below is equivalent to require_safe decorator
@require_http_methods(["GET", "HEAD"])
"""Demonstrate HTTP Request/Response"""
return HttpResponse("Hello World")
Below is an example of an equivalent CBV.
from django.http import HttpResponse
from django.views import View
"""Demonstrate HTTP Request/Response"""
"""Handle GET HTTP method"""
return HttpResponse("Hello World")
Formally, a CBV is any class that inherits from View. The only difference between the two views above is that the View class being inherited will give you automatic handling of HTTP OPTIONS.
Stated otherwise: FV and CBV are *equivalent* with the exception of automatic OPTIONS handling in CBV.
GCBV are simply CBV that have been given behavior. For example, instead of programming a view that shows a template with model data, you can instead inherit a DetailView, and customize it by setting class variables and by overriding methods. For more about that, I recommend looking at https://ccbv.co.uk .
So, when should you use a FV, CBV, or GCBV?
If you are building a view that a GCBV provides behavior for, save yourself time and use it! It's easy to add or slightly modify GCBV behavior, but difficult to remove behavior. The moment you're thinking about removing something a GCBV does, stick to a function or CBV.
So then, for choosing between FV or CBV: Do you need to handle multiple HTTP methods? Is there shared behavior between how the resource is handled by those HTTP methods? If yes, a CBV can help organize that logic and avoid duplicate code.
However, if you have a simple view (typically only one or two HTTP methods must be handled), then a FV will serve you fine (remember the view decorators!).
If you're not sure, start with a FV, and then switch to a CBV or GCBV if appropriate (as complexity goes up or when you realize you can use a GCBV).
Hope that helps,
Andrew
https://jambonsw.com
https://django-unleashed.com

[Yavin Aalto Arba]

I have to +1 Carstens answer.

In short, I too find CB views to be too "magical".

=)

Post by Carsten Fuchs
Hi Andrew,
many thanks for your clear and detailed explanation!
Having used Django for several years, FVs are still my favorite approach
over CBVs and GCBVs. In the past, I made several starts with CBVs, but
never found or understood why CBVs and GCBVs seem to be in many people's
center of attention.
FVs are not only the most simple of the three, but they also have the
virtue of emphasizing the basic generic HTML web functionality and the
way how forms work: The three logical paths that form processing can
take are clearly shown in e.g. this (modified) example from
https://django-book.readthedocs.io/en/latest/chapter07.html
form = ContactForm(request.POST)
# success, now use form.cleaned_data
return HttpResponseRedirect('/contact/thanks/')
form = ContactForm()
# We get here both for GET requests and POST requests
# with invalid forms.
return render(request, 'contact_form.html', {'form': form})
When I was new to Django (and in fact new to serious web development),
understanding this concept, as step by step explained in the above
mentioned chapter, was one of the key insights for me.
CBV and GCBV obscure this imho fundamental concept. Personally, I've
never found the CBV's help with DRY outweigh the clarity of FVs. With
all the attention and efforts that are spent on making getting started
with Django easier for beginners, I was really surprised when even the
official Django tutorials were changed from FVs to CBVs.
I write this email to thank you for your explanation, but also to add
the above thoughts, which I have long been pondering but never found a
place to write down. ;-)
Best regards,
Carsten

Post by Andrew Pinkham
- function views (FV)
- class-based views (CBV)
- generic class-based views (GCBV)
People do not make always make the difference between CBV and GCBV,

which is unfortunate, as they serve different purposes (naming things is
hard). When Andréas states earlier in this thread that "(CBV) use a lot of
defaults for populating your templates, forms and views" that is not 100%
precise. He means GCBV---which provide default (generic) behavior---not CBV.

Post by Andrew Pinkham
Let's break it down. Below is an example of a FV.
from django.http import HttpResponse
from django.views.decorators.http import (
require_http_methods
)
# below is equivalent to require_safe decorator
@require_http_methods(["GET", "HEAD"])
"""Demonstrate HTTP Request/Response"""
return HttpResponse("Hello World")
Below is an example of an equivalent CBV.
from django.http import HttpResponse
from django.views import View
"""Demonstrate HTTP Request/Response"""
"""Handle GET HTTP method"""
return HttpResponse("Hello World")
Formally, a CBV is any class that inherits from View. The only

difference between the two views above is that the View class being
inherited will give you automatic handling of HTTP OPTIONS.

Post by Andrew Pinkham
Stated otherwise: FV and CBV are *equivalent* with the exception of

automatic OPTIONS handling in CBV.

Post by Andrew Pinkham
GCBV are simply CBV that have been given behavior. For example, instead

of programming a view that shows a template with model data, you can
instead inherit a DetailView, and customize it by setting class variables
and by overriding methods. For more about that, I recommend looking at
https://ccbv.co.uk .

Post by Andrew Pinkham
So, when should you use a FV, CBV, or GCBV?
If you are building a view that a GCBV provides behavior for, save

yourself time and use it! It's easy to add or slightly modify GCBV
behavior, but difficult to remove behavior. The moment you're thinking
about removing something a GCBV does, stick to a function or CBV.

Post by Andrew Pinkham
So then, for choosing between FV or CBV: Do you need to handle multiple

HTTP methods? Is there shared behavior between how the resource is handled
by those HTTP methods? If yes, a CBV can help organize that logic and avoid
duplicate code.

Post by Andrew Pinkham
However, if you have a simple view (typically only one or two HTTP

methods must be handled), then a FV will serve you fine (remember the view
decorators!).

Post by Andrew Pinkham
If you're not sure, start with a FV, and then switch to a CBV or GCBV if

appropriate (as complexity goes up or when you realize you can use a GCBV).

Post by Andrew Pinkham
Hope that helps,
Andrew
https://jambonsw.com
https://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
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/3e4ce109-2f24-edfa-0eb3-3426cc52816d%40cafu.de
.
For more options, visit https://groups.google.com/d/optout.

[Jason]

Interesting, because I'm the entire opposite because I find myself
rewriting lots of code when using FBVs compared to (G)CBVs. And then if
one thing changes, that often precipitates a much larger PR than if I were
using equivalent classes. There's no magic involved in them, just regular
object oriented inheritance at play. That said, sites like Classy CBV
<https://ccbv.co.uk/> help a great deal in understanding the background of
what exactly goes in CBVs.