Re: Alternatives to CBVs (class based views)
On Wed, Sep 19, 2012 at 6:42 PM, Cal Leeming [Simplicity Media Ltd] wrote: > Thanks for clarifying, I see where my initial confusion was now. > > The reason this leak hadn't affected our apps was because we didn't use > __init__ to set up the view, instead all the state logic was placed into > __call__. Never the less, having a class call return a HTTPResponse will > break class usage expectations (as mentioned in the wiki), so this still > wouldn't be the cleanest approach. > > I think the majority of users seem to be put off by the complexity of using > ListView/TemplateView, and not the actual class usage itself. If the > documentation highlighted that there was a basic View() object available, it > would make the learning curve a bit easier. > > Russell - Would you have any objection to me submitting a documentation > patch (https://docs.djangoproject.com/en/1.4/topics/class-based-views/) > which shows a basic example of how to use the View() class directly? No objection at all. As I said in my original reply, the biggest problem with CBVs is the documentation - something that is my responsibility. Someone (ahem) needs to do a pretty serious rework (or, at least, expansion) of the CBV documentation to point out all the things that aren't obvious. Danny Greenfeld was taking a look at some of these problems recently, as were a couple of people at the recent PyCon AU and DjangoCon US sprints, so if you want to dig into this, check the tickets before you start serious drafting. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
Thanks for clarifying, I see where my initial confusion was now. The reason this leak hadn't affected our apps was because we didn't use __init__ to set up the view, instead all the state logic was placed into __call__. Never the less, having a class call return a HTTPResponse will break class usage expectations (as mentioned in the wiki), so this still wouldn't be the cleanest approach. I think the majority of users seem to be put off by the complexity of using ListView/TemplateView, and not the actual class usage itself. If the documentation highlighted that there was a basic View() object available, it would make the learning curve a bit easier. Russell - Would you have any objection to me submitting a documentation patch (https://docs.djangoproject.com/en/1.4/topics/class-based-views/) which shows a basic example of how to use the View() class directly? Cal On Wed, Sep 19, 2012 at 12:45 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Tue, Sep 18, 2012 at 7:24 PM, Cal Leeming [Simplicity Media Ltd] > wrote: > > Russell, > > > > On a separate note, I am curious about these 'copy-on-call' leaks, and I > > have not seen this behaviour documented anywhere else. > > > > "The abstraction of the copy-on-call can leak in surprising ways. Some > users > > will try to set up state using an __init__ method (common practice). If > any > > of the state they attach to self in __init__ is mutable (list, dict, > object, > > etc) and they mutate it in the view, this will fail (but not > immediately, or > > in obvious ways)." > > > > Could you elaborate further on this, possibly with a rough example? > > > > Not arguing that CBV approach should be changed, but this copy-on-call > > behaviour is quite unexpected, no? > > The issue is the shallow copy. > > You create a view that sets up state in the __init__ method. Part of > your view's state is held in a mutable object (e.g., a dict, list or > object). The __call__ creates a shallow copy of the view object. A > shallow copy of a mutable object copies the container, but the new > container points to the old content. > > So, if your view logic modifies something held by the mutable object > (which will be a fairly common occurrence), the modification will be > shared by all instances of your view. Hilarity ensues :-) > > You could work around this by using a deep copy, but then you're into > territory where accessing a view could be an incredibly expensive > operation, which is something we want to avoid. It also means anything > you attach to a view must be deep-copyable, which won't always be > true. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
On Tue, Sep 18, 2012 at 7:24 PM, Cal Leeming [Simplicity Media Ltd] wrote: > Russell, > > On a separate note, I am curious about these 'copy-on-call' leaks, and I > have not seen this behaviour documented anywhere else. > > "The abstraction of the copy-on-call can leak in surprising ways. Some users > will try to set up state using an __init__ method (common practice). If any > of the state they attach to self in __init__ is mutable (list, dict, object, > etc) and they mutate it in the view, this will fail (but not immediately, or > in obvious ways)." > > Could you elaborate further on this, possibly with a rough example? > > Not arguing that CBV approach should be changed, but this copy-on-call > behaviour is quite unexpected, no? The issue is the shallow copy. You create a view that sets up state in the __init__ method. Part of your view's state is held in a mutable object (e.g., a dict, list or object). The __call__ creates a shallow copy of the view object. A shallow copy of a mutable object copies the container, but the new container points to the old content. So, if your view logic modifies something held by the mutable object (which will be a fairly common occurrence), the modification will be shared by all instances of your view. Hilarity ensues :-) You could work around this by using a deep copy, but then you're into territory where accessing a view could be an incredibly expensive operation, which is something we want to avoid. It also means anything you attach to a view must be deep-copyable, which won't always be true. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
Russell, On a separate note, I am curious about these 'copy-on-call' leaks, and I have not seen this behaviour documented anywhere else. "The abstraction of the copy-on-call can leak in surprising ways. Some users will try to set up state using an __init__ method (common practice). If any of the state they attach to self in __init__ is mutable (list, dict, object, etc) and they mutate it in the view, this will fail (but not immediately, or in obvious ways)." Could you elaborate further on this, possibly with a rough example? Not arguing that CBV approach should be changed, but this copy-on-call behaviour is quite unexpected, no? Cal On Fri, Sep 14, 2012 at 10:16 AM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > > > On Fri, Sep 14, 2012 at 12:12 AM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> On Thu, Sep 13, 2012 at 12:58 AM, Cal Leeming [Simplicity Media Ltd] >> wrote: >> > Hi all, >> > >> > There is a lot of debate on whether there is a real future for the >> Django >> > CBVs (class based views). >> >> Sigh. > > > Thank you for the detailed response on this - hopefully this thread will > serve as a reference point for people in the future > > >> >> No - there isn't *any* debate about the future of CBVs. There *are* a >> lot of people who apparently don't like them who keep making a lot of >> noise. Every single time I've spoken with one of those people at >> length, the problem has reduced to either: >> >> 1) I don't like classes/OO. There's no winning these people over. > > > Well that's certainly not the reason I dislike them - OO makes views > tidier, simple. > > >> 2) CBV's aren't documented well. You won't get any argument from me >> on (2). I'll take the hit for that -- the initial documentation for >> CBVs was my doing, and it has lots of room for improvement. > > > +1 > > > > >> I'm not aware of anyone in the core that has advocated removing >> class-based views from Django. > > >> > Personally, I find them tedious, and just wanted a >> > way to keep my views clean. >> > >> > So, here is a really minimalistic way of having class based views, >> without >> > the fuss. >> > >> > http://djangosnippets.org/snippets/2814/ >> > >> > This is a fork from: >> > >> > http://stackoverflow.com/questions/742/class-views-in-django >> > http://djangosnippets.org/snippets/2041/ >> > >> > My thanks to eallik for his initial post on stackoverflow for this. >> > >> > Personally I think Django's CBVs should offer a really minimalistic base >> > like this, as well as the existing CBV stuff already in the core - so >> as to >> > not force people into needing to learn an entirely new way of doing >> things, >> > but at the same time allowing them to reap some of the benefits of using >> > callable classes as views. >> > >> > Any thoughts? >> >> What you've described -- a single entry point class-based view base >> class -- *does* exist. It's called django.views.generic.View. Override >> the "dispatch" method, or write a "get/post/put/etc" method, and >> you've got a class-based view. >> > > I noticed this yesterday whilst trawling through the documentation again, > so I will look at this again. > > >> >> I also think you should read the discussions that led to the current >> form of Class-based views. The pattern you've proposed from Stack >> Overflow was one of many suggestions that were made, and were rejected >> because of inherent problems with the approach. The discussions are >> summarised in the wiki: >> >> https://code.djangoproject.com/wiki/ClassBasedViews > > > Thanks for sending this link through, looks very detailed, I will spend an > hour or two reading through it all and put some thoughts back. > > >> >> >> Yours, >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
On Fri, Sep 14, 2012 at 12:12 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Thu, Sep 13, 2012 at 12:58 AM, Cal Leeming [Simplicity Media Ltd] > wrote: > > Hi all, > > > > There is a lot of debate on whether there is a real future for the Django > > CBVs (class based views). > > Sigh. Thank you for the detailed response on this - hopefully this thread will serve as a reference point for people in the future > > No - there isn't *any* debate about the future of CBVs. There *are* a > lot of people who apparently don't like them who keep making a lot of > noise. Every single time I've spoken with one of those people at > length, the problem has reduced to either: > > 1) I don't like classes/OO. There's no winning these people over. Well that's certainly not the reason I dislike them - OO makes views tidier, simple. > 2) CBV's aren't documented well. You won't get any argument from me > on (2). I'll take the hit for that -- the initial documentation for > CBVs was my doing, and it has lots of room for improvement. +1 > I'm not aware of anyone in the core that has advocated removing > class-based views from Django. > > Personally, I find them tedious, and just wanted a > > way to keep my views clean. > > > > So, here is a really minimalistic way of having class based views, > without > > the fuss. > > > > http://djangosnippets.org/snippets/2814/ > > > > This is a fork from: > > > > http://stackoverflow.com/questions/742/class-views-in-django > > http://djangosnippets.org/snippets/2041/ > > > > My thanks to eallik for his initial post on stackoverflow for this. > > > > Personally I think Django's CBVs should offer a really minimalistic base > > like this, as well as the existing CBV stuff already in the core - so as > to > > not force people into needing to learn an entirely new way of doing > things, > > but at the same time allowing them to reap some of the benefits of using > > callable classes as views. > > > > Any thoughts? > > What you've described -- a single entry point class-based view base > class -- *does* exist. It's called django.views.generic.View. Override > the "dispatch" method, or write a "get/post/put/etc" method, and > you've got a class-based view. > I noticed this yesterday whilst trawling through the documentation again, so I will look at this again. > > I also think you should read the discussions that led to the current > form of Class-based views. The pattern you've proposed from Stack > Overflow was one of many suggestions that were made, and were rejected > because of inherent problems with the approach. The discussions are > summarised in the wiki: > > https://code.djangoproject.com/wiki/ClassBasedViews Thanks for sending this link through, looks very detailed, I will spend an hour or two reading through it all and put some thoughts back. > > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
On Thu, Sep 13, 2012 at 12:58 AM, Cal Leeming [Simplicity Media Ltd] wrote: > Hi all, > > There is a lot of debate on whether there is a real future for the Django > CBVs (class based views). Sigh. No - there isn't *any* debate about the future of CBVs. There *are* a lot of people who apparently don't like them who keep making a lot of noise. Every single time I've spoken with one of those people at length, the problem has reduced to either: 1) I don't like classes/OO. There's no winning these people over. 2) CBV's aren't documented well. You won't get any argument from me on (2). I'll take the hit for that -- the initial documentation for CBVs was my doing, and it has lots of room for improvement. I'm not aware of anyone in the core that has advocated removing class-based views from Django. > Personally, I find them tedious, and just wanted a > way to keep my views clean. > > So, here is a really minimalistic way of having class based views, without > the fuss. > > http://djangosnippets.org/snippets/2814/ > > This is a fork from: > > http://stackoverflow.com/questions/742/class-views-in-django > http://djangosnippets.org/snippets/2041/ > > My thanks to eallik for his initial post on stackoverflow for this. > > Personally I think Django's CBVs should offer a really minimalistic base > like this, as well as the existing CBV stuff already in the core - so as to > not force people into needing to learn an entirely new way of doing things, > but at the same time allowing them to reap some of the benefits of using > callable classes as views. > > Any thoughts? What you've described -- a single entry point class-based view base class -- *does* exist. It's called django.views.generic.View. Override the "dispatch" method, or write a "get/post/put/etc" method, and you've got a class-based view. I also think you should read the discussions that led to the current form of Class-based views. The pattern you've proposed from Stack Overflow was one of many suggestions that were made, and were rejected because of inherent problems with the approach. The discussions are summarised in the wiki: https://code.djangoproject.com/wiki/ClassBasedViews Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
It would be helpful to see some more complex examples with these classes. One thing I like about the CBVs is that they include all of the necessary code for common functions. I have used them extensively (once I figured them out). On Wednesday, September 12, 2012 12:59:12 PM UTC-4, Cal Leeming [Simplicity Media Ltd] wrote: > > Hi all, > > There is a lot of debate on whether there is a real future for the Django > CBVs (class based views). Personally, I find them tedious, and just wanted > a way to keep my views clean. > > So, here is a really minimalistic way of having class based views, without > the fuss. > > http://djangosnippets.org/snippets/2814/ > > This is a fork from: > > http://stackoverflow.com/questions/742/class-views-in-django > http://djangosnippets.org/snippets/2041/ > > My thanks to eallik for his initial post on stackoverflow for this. > > Personally I think Django's CBVs should offer a really minimalistic base > like this, as well as the existing CBV stuff already in the core - so as to > not force people into needing to learn an entirely new way of doing things, > but at the same time allowing them to reap some of the benefits of using > callable classes as views. > > Any thoughts? > > Cal > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/tCY5GSuWfOcJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
Ah, thanks for letting me know - the original snippet by eallik had support for this, but I must have stripped it out not realising. On Thu, Sep 13, 2012 at 1:34 AM, Matt Schinckel wrote: > One really small nitpick: when returning a 405, it is a requirement that > you return a header with the acceptable methods: >> >> > > 10.4.6 405 Method Not Allowed > > > The method specified in the Request-Line is not allowed for the resource > identified by the Request-URI. The response MUST include an Allow header > containing a list of valid methods for the requested resource. > > (From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/8vKvmPp9uTgJ. > > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
One really small nitpick: when returning a 405, it is a requirement that you return a header with the acceptable methods: > > > 10.4.6 405 Method Not Allowed > The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. (From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/8vKvmPp9uTgJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
I guess I'm the only one who loves Django's CBVs :( Maybe some good documentation / third-party tutorial is in order? haha Thanks for sharing though, Cal! -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/VbBXiSspPA8J. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
Op 12 sep. 2012 18:58 schreef "Cal Leeming [Simplicity Media Ltd]" < cal.leem...@simplicitymedialtd.co.uk> het volgende: > > Hi all, > > There is a lot of debate on whether there is a real future for the Django CBVs (class based views). ..snip.. > > Any thoughts? > I understand what you're getting at and agree in principle, but you're not exactly feature compatible. ;-) > -- > You received this message because you are subscribed to the Google Groups "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
On Wed, Sep 12, 2012 at 7:44 PM, Javier Guerra Giraldez wrote: > On Wed, Sep 12, 2012 at 11:58 AM, Cal Leeming [Simplicity Media Ltd] > wrote: > > So, here is a really minimalistic way of having class based views, > without > > the fuss. > > > > http://djangosnippets.org/snippets/2814/ > > looks nice. i like that it respects the idea that views in Django are > just callables that take a reques (plus optional extra params) and > return a response. to get inheritance, just make callable objects and > spread functionality as desired. > Yeah I was really pleased when I found the original snippet, and this approach can be extended on so easily too. > > the generic view functions are good for prototyping, but soon you have > to replace with your own, which is not difficult. the problem with > generic CBV is that they try to factorize every feature so thinly that > the inheritance becomes an unholy mess. any simplification would > either reduce functionality, or make some features harder to replace, > so there doesn't seem to be a way out... apart from not using them. > Agreed, the CBVs in Django leave me with the same taste that django-tastypie left in my mouth - making a very simple thing overly complex. This is why I'm wondering if the way forward is to offer two types of CBV, one using the current CBVs in Django, and one using an approach like this. > -- > Javier > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Alternatives to CBVs (class based views)
On Wed, Sep 12, 2012 at 11:58 AM, Cal Leeming [Simplicity Media Ltd] wrote: > So, here is a really minimalistic way of having class based views, without > the fuss. > > http://djangosnippets.org/snippets/2814/ looks nice. i like that it respects the idea that views in Django are just callables that take a reques (plus optional extra params) and return a response. to get inheritance, just make callable objects and spread functionality as desired. the generic view functions are good for prototyping, but soon you have to replace with your own, which is not difficult. the problem with generic CBV is that they try to factorize every feature so thinly that the inheritance becomes an unholy mess. any simplification would either reduce functionality, or make some features harder to replace, so there doesn't seem to be a way out... apart from not using them. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
