On Thu, Jun 17, 2010 at 1:05 PM, Roald <downa...@gmail.com> wrote: > On 17 jun, 12:16, Patryk Zawadzki <pat...@pld-linux.org> wrote: >> On Thu, Jun 17, 2010 at 11:53 AM, Roald <downa...@gmail.com> wrote: >> > On 16 jun, 15:45, Ben Firshman <b...@firshman.co.uk> wrote: >> >> The request is passed round so methods look like views to decorators. >> >> Magically dropping it for decorators seems a bit scary. :/ >> >> > Just brainstorming: couldn't you have View derive from HttpRequest? >> >> Would you seriously recommend people to extend "int" when they want to >> implement multiplication? :) > > Nope. But the analogy doesn't hold. > > First: this is just brainstorming. Maybe it inspires someone for a > better solution somehow. As you might know, I (still) favor deriving > from HttpResponse > > Second: users will never extend HttpRequest directly, they will extend > View. > > Third: It might be not even as weird as it looks on first sight. > There's nothing wrong with 'response = request.get_response()', so why > not just make 'get_response' the 'default function' of a request: > response = request(). I admint that the name View might nog be the > best in this case. > > Fourth: still, this is just brainstorming. >
A few points: 1) With inheritance, you should be able to say Derived is-a Base, eg 'a Car is-a Vehicle'. A view is NOT a response, however you wrap it up. A view is a generator that when called with a request, results in a response, whether it is a class based view, or a function based view. Does a view have headers or a mime type? Perhaps you need to start using different names for these classes, because inferring that 'a view is-a response' just sounds stupid. 2) I extend HttpResponse. In lots of places. (more to the __new__ approach) 3) One of the purposes (as far as I can see) of having the view as a class is to allow non volatile application data to be instantiated outside of the request-response lifecycle. In the proposed approach, each request is effectively given its own cloned view object with which to generate the response. Surely this means this use case is no longer achievable? If it is, how? (I'm probably missing something!) If it isn't, then what _is_ the use case for class based views? Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
