--You received this message because you are subscribed to the Google Groups "Django developers" group.To post to this group, send email to django-d...@googlegroups.com.To unsubscribe from this group, send email to django-develop...@googlegroups.com.For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
I am not ready to judge right now wether they are a good idea or not.I can completely agree that documentation makes the views more difficult then they actually are. Every time I create a new view, I find myself going to the source. I think this is a case where the learning curve initially is a little steeper so better examples and best-practices will really help with people's implementation and also this discussion.
This is the real issue. The docs.
My feeling is that though some people might have uses for CBV, weshouldn't be suggesting that developers should prefer CBV to functionbased views. When it comes to maintainability, FBV are better, and Iwould agree that they are more Pythonic.When I tried to use CBV, I found the inheritance semantics lead tounexpected results when composing mixins. I wanted to spend my timecreating web apps and not debugging to figure what 3 lines of gluecode I would have to write in the correct overridden method to makeCBV work for me in my usecase. At the time I felt of have a list ofsay context providers would have made more sense than mixins.
Class Based View are awesome, except the ones which are built in?
I agree, as has been suggested, that if you make a really flat classbased views like the admin itself, you can gain some benefits, but Istill think those benefits are heavily tied to assumptions one canmake in a specific problem space. Keeping the ability to create aClass Based View has value, but it is up to to the people who likethem to show the rest of us how they can be used with out creatingmore problems then they solve, and just because they exist doesn'tmean they should be used more than they are. Apparently when it comesto generic class based view they should be used less.
I'm not suggesting that CBVs make it harder to test (I actually think it should be no different because the tests should avoid being implementation specific). I just feel that the pattern of testing/refactoring is different than the typical TDD approach (one could argue that this is not necessarily a bad thing - but that's a whole another can of worms).
I think Marc makes a very valid point about CBVs being well suited for unit testing. This I agree with. But I typically try to avoid unit testing as much as possible in favour of a more "outside-in" approach (ie. integration testing).
For example, I would avoid unit testing the "get_context_data" method on a CBV and instead have a test that performs a request on the view and tests the context variables.
I'm beginning to think that the divisions on this issue among developers might be tied to development style. This would explain why some people love them and some people hate them.
On Tuesday, June 5, 2012 2:02:14 AM UTC-4, Marc Tamlyn 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/-/_9hq-OjYc3wJ.
Carl
On Tuesday, June 5, 2012 at 9:55 AM, Zach Mathew wrote:For example, I would avoid unit testing the "get_context_data" method on a CBV and instead have a test that performs a request on the view and tests the context variables.This is going to be slower than just unit testing get_context_data.
On Tuesday, June 5, 2012 at 11:11 AM, Albert O'Connor wrote:
Both the Built in Generic Class Based Views, and Class Based Viewsin general are great. Generic Class Based Views are not awesome whenyour view is not generic.My experience is using Generic Class Based Views as an inspiration forones own Class Based Views lead to a bad user experience, both formyself and apparently other people. I think it is worth highlight inthe documentation that Generic Class Based Views are useful, butapparently not how you should write your own.
Mixing in your UserMixin with other mixins that do additional querymodifications will lead to the writer of code having to create newmixin which either combines both lines of code into one throughcopying or explicitly calling each mixin, which will itself beadditional lines of code.
I can see an argument for using CBV to create library views which areexpected to both be reused and customized extensively, but those CBVshould themselves be flat with a very clear execution model. Usinginheritance to override behaviour with the syndication framework worksbecause you only have to look at one class to see what behaviour youare modifying, but it doesn't scale to a any number of mixins, exceptmany for the one your provide in your distinct use case.It should be noted a vast majority of views that developers writewhich aren't "generic" will never ever be reused and thus probablyshould be CBV.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at--You received this message because you are subscribed to the Google Groups"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at
--<><><>< Albert O'Connor - amjo...@gmail.com--You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at--You received this message because you are subscribed to the Google Groups"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at
--<><><>< Albert O'Connor - amjo...@gmail.com--You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com.