Will function based views ever be deprecated?

[Some Developer]

Hi,

I was wondering if function based views will ever be deprecated? I
absolutely hate class based views with a passion for various reasons
(too complex, trying to solve a problem that doesn't exist etc). With a
function based view I can write it in 2 minutes pretty much and handling
multiple forms on the same page is a piece of cake. The same is not true
of class based views. You need to look up which classes a certain class
based view inherits from to see what methods are available, handling
multiple forms on the same page is a pain in the arse if not impossible
and various other things that are just way more difficult than they
should be.

So yeah. Are function based views ever going to go away? I've already
noticed that in Django 1.11 the login() and logout() functions are going
away in favour of class based views which seems silly as I'll have to
rewrite my perfectly working user app to use class based views now.

Is that a sign of things to come? If that is what the developers are
planning can I please beg them to reconsider? Function based views are
just fine. You might prefer class based views but there are users out
there who much prefer function based views.

Please don't take this as an aggressive post. I love working with Django
and I'm just passioniate about it. This isn't a flame post.

Thank you for any help :).

Some Developer.

[George Silva]

In the end, cbvs are functions. So no, I don't they come to an end soon.

I love function based views.

--
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...@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/a604368c-0b58-840b-3143-5425e6b73b5a%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

[James Bennett]

If you're asking "Will there ever be a point when all built-in views in Django are class-based", the answer is "maybe", because whether to write one of those class-based or function-based depends on what the view needs to do, how much configurability/extensibility it needs to support, etc.

If you're asking "Will there ever be a point when Django no longer supports using functions as views, period", the answer is almost certainly "no".

Officially, the definition of a Django view is a Python callable which takes an HttpRequest object as its first positional argument, and which either returns an HttpResponse object or raises an exception. That definition is unlikely to change.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGyPVTuyqCA-DTY9%3D%2BhO6DaWRSTt8ooz%2BKnFKrbXuqF4tUyKkQ%40mail.gmail.com.

[Antonis Christofides]

Hi,

This is not an answer to your question (which was answered by James Bennett anyway), but I liked this recent article about class vs. function based views:

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

This is his conclusion:

I usually always start my views as function-based views. If I can use a generic class-based view just by overriding the attributes, I go for it. If I have some very specific needs, and it will replicate across several views, I create my own custom generic view subclassing the django.views.generic.View.

Regards,

A.

Antonis Christofides
http://djangodeployment.com

[Some Developer]

Hi,

I've just re-read my message and notice that it is extremely aggressive.
I want to apologies for that. When I typed it I had just had a big
argument with someone and it came across in my message to this list.
That was uncalled for and I'm not normally that type of person. So sorry
again.

If I post again I'll make sure to only do it when I am nice and happy :).

Some Developer.

[Some Developer]

Hi,

Thank you for the link. I'll check it out.

[Some Developer]

Hi,

Awesome thanks. I can see the reason for some class based views as they
remove the need for boilerplate code but if you run into a problem with
them for whatever reason you generally have to dig out the Python
debugger and set a break point in your view to see what the Django
framework code is doing in the background.

I can write just about any view I want in less than 5 minutes with a
function based view. The only slow down on my end is my typing speed. I
just find them much easier to understand and debug when you can look at
the entire code for the view with nothing else getting in the way.

I think I will try again to use some class based views in my code just
so I can make a more informed decision. I just remember my last attempt
to use the FormView class based view with multiple forms on the same
page and giving up in disgust because it was so much harder than doing
the same thing in a function based view.

Some Developer.

[Andréas Kühne]

I find it interesting that so many haven't embraced the new CBV's. I ONLY use CBV's when designing and find the usages much simpler - because of no boilerplate and also the fact that I can derive from other classes when needed.

Of course - the first time you use a form view or a template view and you find yourself having problems - debugging that could take a while, however, once you have done that I really haven't seen this as an issue. Also because most of the default views inherit from the same mixins - once you have understood how one works - you usually get the hang of it. 

It could be that the first thing I did in django was to refactor views from function based to class based - and therefore haven't started exploring FBV's more :-)

Just my 2 cents...

Regards,

Andréas

--
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...@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/e8af988b-3fd2-f781-e33b-00fa9b2b205f%40googlemail.com.

[Some Developer]

Try doing something that a class based view doesn't support out of the
box and then you'll understand why function based views are still used.
Even something as simple as returning some JSON means you have to dig
into how a class based view works where as it is about 3 lines of code

in a function based view.

Then what about a view that has to handle 2 (or more) different form
classes on the same page? You'll soon find that having to do that in a
class based view means major work rewriting or building your own class
based view.

As I said I'll give them another go but I've yet to be convinced of
their greatness.

On 03/04/2017 15:54, Andréas Kühne wrote:
> I find it interesting that so many haven't embraced the new CBV's. I
> ONLY use CBV's when designing and find the usages much simpler - because
> of no boilerplate and also the fact that I can derive from other classes
> when needed.
>
> Of course - the first time you use a form view or a template view and
> you find yourself having problems - debugging that could take a while,
> however, once you have done that I really haven't seen this as an issue.
> Also because most of the default views inherit from the same mixins -
> once you have understood how one works - you usually get the hang of it.
>
> It could be that the first thing I did in django was to refactor views
> from function based to class based - and therefore haven't started
> exploring FBV's more :-)
>
> Just my 2 cents...
>
> Regards,
>
> Andréas
>
> 2017-04-03 13:52 GMT+02:00 Some Developer <someukd...@gmail.com

> <mailto:someukd...@gmail.com>>:

[Vijay Khemlani]

Any function based view can be reduced to a CBV trivially

class MyView(View):

   def get(request):    # or post, or whatever http method

      ....

Point is there are patterns that repeat themselves enough to justify CBV, aside from the benefits of using classes (inheritance, mixins, etc).

Also

"I can write just about any view I want in less than 5 minutes with a function based view. The only slow down on my end is my typing speed."

If your typing speed is the limiting factor in your workflow... *shudders*

On Mon, Apr 3, 2017 at 12:01 PM, Some Developer <someukd...@gmail.com> wrote:

Try doing something that a class based view doesn't support out of the box and then you'll understand why function based views are still used. Even something as simple as returning some JSON means you have to dig into how a class based view works where as it is about 3 lines of code in a function based view.

Then what about a view that has to handle 2 (or more) different form classes on the same page? You'll soon find that having to do that in a class based view means major work rewriting or building your own class based view.

As I said I'll give them another go but I've yet to be convinced of their greatness.

On 03/04/2017 15:54, Andréas Kühne wrote:

I find it interesting that so many haven't embraced the new CBV's. I
ONLY use CBV's when designing and find the usages much simpler - because
of no boilerplate and also the fact that I can derive from other classes
when needed.

Of course - the first time you use a form view or a template view and
you find yourself having problems - debugging that could take a while,
however, once you have done that I really haven't seen this as an issue.
Also because most of the default views inherit from the same mixins -
once you have understood how one works - you usually get the hang of it.

It could be that the first thing I did in django was to refactor views
from function based to class based - and therefore haven't started
exploring FBV's more :-)

Just my 2 cents...

Regards,

Andréas

2017-04-03 13:52 GMT+02:00 Some Developer <someukd...@gmail.com

<mailto:someukdeveloper@gmail.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...@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/7d612ef6-4438-70ab-9aea-d5595af22e5a%40googlemail.com.

[Some Developer]

Most views are incredibly simple. Query database, maybe do a security
check on the logged in user if the data shouldn't be public or only some
users / groups can view it (yeah one thing I don't use as often as I
should but will be using more of in the future is the built in Django
permissions system), return data and add it to template context. Done.

Forms might add a couple of minutes per form. Just need to check that
each form is valid and save the results or do the database search as
required. Neither requires much programming time or skill.

I don't see why any of that should take any more than 5 minutes. Before
I started programming in Python / Django I was a C programmer. Now that
takes time because there are so many mistakes you can make in C unless
you are on the ball. In comparison Python and Django is a piece of cake.

The thing that takes the time is planning out features and making sure
your unit tests are comprehensive. Also making sure your models are well
designed. I can easily spend 2 times the amount of time planning out
features than I do actually programming and my philosophy when it comes
to programming is have the absolute bear minimum of code in your views.
If you can get rid of code then do so.

[Andréas Kühne]

I really think you should revisit CBV's - you don't have to use the generic views unless they make sense. I regularly override most of my own with mixins and the like. And like you said - querying the database and returning a template is probably one of the most common things I do. That's a detail view and 3 rows of code.

I understand that you like the way you work - but I think CBV's is probably one of the greatest additions to django - mostly because of mixins and inheritance. 

Regarding the need to use 2 forms in the same view - I haven't stumbled across that usecase yet - but I probably wouldn't have an issue in CBV's either - but couldn't use the generic FormView for that though.

Regards,

Andréas

--
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...@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/30a5eab2-dee9-eaff-66e4-105ba85bf0bf%40googlemail.com.

[Andrew Pinkham]

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

[Some Developer]

I'm about to start a new website and I'll make it a point to use some
generic class based views when I think they are appropriate. I'll also
try and move my custom user application that I use for all of my
projects over to class based views as wells. Especially as the login()
and logout() functions are being deprecated in the next release and
being replace with class based views.

I'm sure I'll get the hang of them. I think the main problem I have is
that I haven't memorised them yet. I've pretty much memorised everything
that I need to do with function based views (with a few exceptions which
are not that hard to look up). I guess once I have memorised everything
that I need to know I'll be back being productive with them.

Hopefully it all goes OK :).

[Some Developer]

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.

[Antonis Christofides]

> I've just re-read my message and notice that it is extremely aggressive. I
> want to apologies for that. When I typed it I had just had a big argument with
> someone and it came across in my message to this list. That was uncalled for
> and I'm not normally that type of person. So sorry again.

Hello,

I don't think you need to apologize. Your message was a bit agitated perhaps,
but I wouldn't call it aggressive. Agitated is fine—it goes straight to the
pain. I also liked the ensuing discussion, and I guess many people did, because
seeking the ideal structuring of the code is an endless quest.

Regards,

A.

Antonis Christofides
http://djangodeployment.com

[Jani Tiainen]

Hi,

There also exists django-vanilla-views [1] which are a bit simplified
version of generic class based views. You may find them easier to cope
with (less magic).


[1] http://django-vanilla-views.org/

--
Jani Tiainen

[Andréas Kühne]

Very good explanation Andrew, I'm looking forward to having time to look at your talk - seems right on the money.

Regards,

Andréas

--
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...@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/BD0905CB-9D16-4F9A-8CBD-7115B3E46303%40andrewsforge.com.