Comment by po | Hacker News Reader

Comment by po | Hacker News Reader

Contrary to somewhat popular belief, Django's function-based views are not deprecated and as far as I know, there are no plans to remove them. Django's class-based views were introduced and the generic views ported over to the CBV style (the older FBV versions were deprecated), however after giving it a go in a small part of our app, I found them to be overly-complex and hard to extend and went back to FBV.

In my opinion, Django's CBV's are polarizing. Some people really love them as a way to reuse code (e.g. they are recommended glowingly in the popular Two Scoops of Django book) and people like me don't. I feel like inheritance is a poor way of modeling views and reusing code.

Whenever anyone voiced complaint about the CBV system, it usually was mixed in with complaints about the implementation of the generics. The response was always, "you don't have to use the generics provided, write your own." I'm really glad to see that Tom went exactly that route, and I'm happy that Django as a system is flexible enough to allow it. I may not be 100% convinced just yet but I'm willing to try this out and it seems like a definite step in the right direction to me. Nice work.

I've always liked CBV's, despite their complexity. Something just seemed more "right" about them than FBV's. That being said, the designers unquestionably got a bit class-happy, and it's almost impossible to use CBV's in any nontrivial way without dipping into the library source code (well written and documented as it may be) to truly understand the control flow between the overrides.

I definitely hear you on inheritance. I'm becoming more convinced that inheritance in many cases is a crutch that prevents a much more reasonable control flow and maintainable design that can be achieved compositionally.

The mixing of inheritance and mixins in the canonical CBV design is tricky, to say the least. I guess it was done with the expectation that people would more directly use the mixins and base classes, but in reality, people tend to try to extend the leaf classes and the class tangle gets exacerbated. This project seems like a huge step in the right direction.

I have been looking at them (but not using them) for a while because I cant see why I would want to re-use a view + it seem s like they require more work to implement then

if request.method == "POST":

   return render_request('template.html", params)

The basic concept doesn't make a big difference. The real meat is the generic model views, not the base CBV, imo.

It may not be revolutionary, but extending an UpdateView to block anonymous users and throwing a mixin that limit access to the objects the current user owns, I can have my "edit a blog post" view looking like:

  class EditBlogPost(OwnedObjectsMixin, AuthenticatedUpdateView):
    model = Blog
    form = BlogForm

and all I have left to do is put my template, which is quite nice (especially when the List, Create, Delete views are about the same length in code).

It gets less useful (and more convoluted) as your views get further away from basic CRUD stuff, but I still feel it's quite useful.

(Edited: the difference is more clear on the "Update" view)

As opposed to two decorators on the blog module's edit method? I'm not sure a ClassView grants us any advantages for this use.

  @is_authenticated
  @is_owner
  def edit(self):
    ...

The decorator can only add behavior prior to the original function's execution, and many decorators may not necessarily be applied together. CBVs allow a composition of mixins that can include behavior that's substantially more complicated and can deal with any of the methods and members defined for the view.

A well-defined base CBV allows you to limit the use of RequestContexts, checks for method types, and special validations. For small projects it may not make a difference; for projects with at least couple dozen views and a bunch of common behavior, they increase readability tremendously.

Also, they offer a very good template for defining view behavior. Once you're familiarized with CBV method definitions it's much easier to grok code, as the view flow is much more standardized than for regular function views.

> I may not be 100% convinced just yet but I'm willing to try this out and it seems like a definite step in the right direction to me.

Thanks po - that's exactly the kind of response I was hoping for.

> In my opinion, Django's CBV's are polarizing [..] I feel like inheritance is a poor way of modeling views and reusing code.

I share your opinion on CBV. Personally I like the old function-based views because everything happens in that little block of code and I know exactly the order in which something happens. CBV quickly get me lost in the chain of method calls across classes.

prior to asp.net mvc or those master page things, every asp.net project I ever worked on eventually had a base webform which was the dumping ground for everything and thus nightmarish to comprehend or maintain. Django's CBV's remind me of that nightmare and I tend to avoid them because it feels like reinventing a poorly designed wheel with no real value.

I occasionally see comments on threads claiming they are the best thing since sliced bread, but rarely can anyone back it up convincingly.

So, to me they feel like a fad, and should be avoided IMO.

Reply on news.ycombinator.com