If you pollute the namespace with small helper functions you can test them 
independently and use them outside single CBV. This style also helps to 
write less coupled code - all dependencies are visible (they are all in 
functions' params list) so this forces developer to rethink the 
decomposition and write small functions with less arguments (and thus less 
dependencies) and so such functions are more reusable and it is easier to 
test them because they need less state information and the output is (or 
should be) simpler.

This 'library' approach is opposite to 'framework' approach when you're 
given a class that almost solve your problem and then customize it to make 
it solve your problem. With 'library' approach you're given small building 
blocks and use them to implement the necessary logic. 

I think both approaches are useful in different circumstances. We shouldn't 
say one approach is superior to another. I personally found FBV and 
'library' approach to writing views suite my needs better but experience 
may vary.

-1 for rewriting to CBV for the sake of rewriting; +1 for adding a clear 
note to docs that FBVs are not deprecated. It seems there is a lot of 
confusion about this.

вторник, 5 июня 2012 г., 21:33:53 UTC+6 пользователь dstufft написал:
>
>  
>  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> 
> 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.
>
>  
>  
вторник, 5 июня 2012 г., 21:33:53 UTC+6 пользователь dstufft написал:
>
>  
>  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> 
> 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.
>
>  
> 

-- 
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/-/ABHjWe_phYwJ.
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.

Reply via email to