This is a great example why framework projects could benefit from being a bit more democratic. Most people seem to be pulling their hair out, telling you something is too complicated to effectively use. The response: It's worth it once you learn. The complexity cost is worth it. Trust us. Read the docs (of course), use this 3rd party site (ok...), read the code. (so I can write a non-trivial view!?). If you are still giving that answer years later, you have to be open to the fact that that your users might be on to something.
Often when you hear someone say they're using CBGV on a large project, you can almost sense the pause for applause.
And that is not a happy place to end up when you're just starting out with them, since in there you're seeing the whole inheritance/mixin layout structure, which is what leads to the belief that it's too complicated to use.
Which... no, class-based generics are pretty darned easy. Here are the views for my blog app, for example:
https://github.com/ubernostrum/blog/blob/master/blog/views.p...
It'd be nice to cut down the use of super(), but that's about the only issue I have with it. All of the simpler-CBV implementations I've seen make a few too many assumptions for my personal taste, or otherwise cut down on flexibility in favor of simplifying the inheritance diagram, which I don't agree with as a goal in itself.
For the docs: "If you believe you've found some behaviour in Django's generic class-based views that can't also be trivially achieved in django-vanilla-views, then please open a ticket, and we'll treat it as a bug."
You shouldn't be losing any flexibility by using it instead of using Django's existing GCBV implementation.