My feeling is that though some people might have uses for CBV, we shouldn't be suggesting that developers should prefer CBV to function based views. When it comes to maintainability, FBV are better, and I would agree that they are more Pythonic.
When I tried to use CBV, I found the inheritance semantics lead to unexpected results when composing mixins. I wanted to spend my time creating web apps and not debugging to figure what 3 lines of glue code I would have to write in the correct overridden method to make CBV work for me in my usecase. At the time I felt of have a list of say context providers would have made more sense than mixins. If people have uses for CBV, they should be available, but advocating that more builtin or contrib views should be made class based is something I would be against personally, unless it really made sense in a specific use case. Albert O'Connor On Tue, Jun 5, 2012 at 2:02 AM, Marc Tamlyn <[email protected]> wrote: > There is a plan to do some work on the docs at the djangocon sprints - in > particular trying to get some examples of when you 'could' and when you > 'should not' use the generic CBVs. > > With regards to Zach's point about TDD testing - some of that may simply be > familiarity. I don't know about you but it would have been very difficult > for me to get into successfully TDDing a functional view until I'd written > several dozen views and knew what the pattern is. You can still test the CBV > top to bottom, exactly as you would with a function based view. Yes there > may be some shift to conventions, but that will come with familiarity. > > I think part of the important difference is that when you look at a CBV for > the purposes of unit testing it, you feel very quickly that you should be > testing the individual methods. This is actually really nice and gives a lot > more branch-coverage without rerunning the same 4 database queries every > time for variables which aren't used. Without CBVs a complex view can easily > extend over 50 or so lines, whereas it's more natural to split this up and > test the sections independently with a Class based system. I know in general > we should be 'writing less view code' and pushing the logic elsewhere, but > that depends on what that logic is - for example the view layer needs to > decide whether to return JSON or HTML depending on certain headers in the > request, and that is more easily testable as an overridden render to > response method than as the last 4 lines of a 50 line view. > > Marc > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- ><><><>< Albert O'Connor - [email protected] albertoconnor.ca | wildernesslabs.ca | watpy.ca -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
