On Tuesday, June 5, 2012 at 11:11 AM, Albert O'Connor wrote:
> > Both the Built in Generic Class Based Views, and Class Based Views > > in general are great. Generic Class Based Views are not awesome when > > your view is not generic. > > > > > My experience is using Generic Class Based Views as an inspiration for > ones own Class Based Views lead to a bad user experience, both for > myself and apparently other people. I think it is worth highlight in > the documentation that Generic Class Based Views are useful, but > apparently not how you should write your own. > > The GCBV's tried to go very far into reusability, to the point where they have several layers of indirection to what is going on. Personally I prefer a case where you have the base view which is well written and contains all of the "Base" functionality instead of having a base view which is actually comprised of half 3-6 different Mixins. However adopting some of their conventions into your own CBV's will go a long way (get_object, get_queryset etc). > > Mixing in your UserMixin with other mixins that do additional query > modifications will lead to the writer of code having to create new > mixin which either combines both lines of code into one through > copying or explicitly calling each mixin, which will itself be > additional lines of code. > > This is only true if you write poor mixins. > > I can see an argument for using CBV to create library views which are > expected to both be reused and customized extensively, but those CBV > should themselves be flat with a very clear execution model. Using > inheritance to override behaviour with the syndication framework works > because you only have to look at one class to see what behaviour you > are modifying, but it doesn't scale to a any number of mixins, except > many for the one your provide in your distinct use case. > > It should be noted a vast majority of views that developers write > which aren't "generic" will never ever be reused and thus probably > should be CBV. > > I assume you meant shouldn't be here. There are benefits beyond the reusability (which the reusability is something I speak a lot about), in terms of testing, breaking things into easier to digest chunks. Even the most non-generic view tends to create a good deal of boilerplate. Even something as simple as the default get() and post() methods reduces the amount go cognitive overhead needed while parsing what a view does. As an example a dummy: https://gist.github.com/2875669 Similar number of lines (intact the CBV is a bit more), however with the CBV I've broken my view down into smaller chunks which, other then via self, are not able to affect one another. This allows me to focus on a much smaller unit of code if I am debugging making me have to "page" less of the application into my head at once. (As an example, maybe the post method accidentally reuses a variable from the setup code that the generic code was expecting to be there). Even if all you use the CBV's for is a "Namespace to hold crap" I feel that your code will end up better as it enables you to break apart a view into smaller and more manageable chunks, without polluting the views.py namespace with multiple functions for every view. > Albert > > On Tue, Jun 5, 2012 at 10:46 AM, Donald Stufft <donald.stu...@gmail.com > (mailto:donald.stu...@gmail.com)> wrote: > > On Tuesday, June 5, 2012 at 10:35 AM, Carl Meyer wrote: > > > > > > > > On 06/05/2012 08:12 AM, Donald Stufft wrote: > > > > In order to do this with FBV's i'd either need to modify the existing > > FBV to accept > > a parameter that says if it should filter by logged in user or not or > > copy/paste > > the code into a new FBV. > > > > > > Not true, you can also have a function view that returns a > > TemplateResponse, and do the same types of tweaks using reusable decorators. > > > > Maybe in that exact case. You can take the example further and have the same > > or another Mixin also handling setting the user field of model instance > > (which on > > a tangent, is one of the places Generic CBV's can improve imo). So now you > > can > > Mixin automatically setting the ``user`` field of a Model to the currently > > logged in user. > > > > You could also be calling an external API, and want to pass additional data > > to that > > API in this instance of the view, TemplateResponse won't help you and the > > original > > options stand here where you either copy/paste the view, or modify the > > existing > > view. > > > > It's pretty much a fact that module level functions in Python are completely > > unable > > to deal with any modification to internal logic without building up a list > > of kwargs/flags > > that they accept. Even if you are forward thinking and break your FBV's into > > multiple > > sub functions that the actual view calls, you cannot modify how it calls > > those functions, > > or swap out which functions it calls without getting into hacky monkey > > patching or copy > > and pasting things. > > > > > > Carl > > > > -- > > 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 > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto:django-developers+unsubscr...@googlegroups.com). > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > > > > > -- > > 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 > > (mailto:django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com > > (mailto:django-developers+unsubscr...@googlegroups.com). > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > > > > > > -- > > <><><>< Albert O'Connor - amjoc...@gmail.com (mailto:amjoc...@gmail.com) > > 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 django-developers@googlegroups.com > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
