> 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. 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. 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. Albert On Tue, Jun 5, 2012 at 10:46 AM, Donald Stufft <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. > 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. > > > -- > 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. -- ><><><>< Albert O'Connor - 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. 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.
