On Thu, Jun 17, 2010 at 3:32 PM, Tom Evans <tevans...@googlemail.com> wrote:
> 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.
I'd like to add here that we already discussed the biggest
disadvantage of deriving from HttpResponse:
With this approach you can't easily pass the request to some other view:
def main_view(request, ...):
if ...:
return sub_view(request, ...)
else:
return other_sub_view(request, ...)
This is a common pattern and it can occur somewhere deep within the
view code. The HttpResponse approach doesn't provide an easy solution.
It doesn't even provide an easy solution for returning
HttpResponseRedirect or other HttpResponse subclasses, as you already
identified.
> (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?
It's still possible in exactly the same way as you do it today:
mydata = ...
urlpatterns('', url('...', 'MyView', {'outside_of_lifecycle': mydata}))
Alternatively, you can derive from MyView:
class SubMyView(MyView):
ouside_of_lifecycle = mydata
However, I don't think that this is the use-case of class-based views
(you can achieve the same with function-based views). The whole point
is being able to reuse as much code as possible while allowing to
flexibly modify the view's behavior at a rather fine-grained level.
Take a look at the Feed view in Django (or look at ModelAdmin from the
admin interface if you prefer):
http://docs.djangoproject.com/en/dev/ref/contrib/syndication/
You can customize the query that gets executed and you can customize
every single field that gets displayed in the feed. It's very easy and
flexible and in contrast to function-based views you don't need to
rewrite the whole view from scratch to change a little detail.
Bye,
Waldemar Kornewald
--
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.
