2

I'm reading Two Scoops of Django: Best Practices for Django 1.8 where it is suggested to always use generic class based views.

So I'm trying to convert a page where I display a list of objects (def objects_listing(request)) into a class derived from ListView (class ObjectsList(ListView)).

The problem is that my view not only is needed to display a list of objects but also:

  • A search form to filter these objects (which links on the same view);
  • A list of categories of objects.

The solution appears to be to override the function get_context_data to provide additional context to the template (see documentation).

My question is: is it still considered best practice to use ListView in this case? Or should I stick to a normal view instead? Which are the pros and cons of these approaches?

Pros of ListView:

  • The paginator works automatically in the ListView if you provide a page argument with GET. No need to pass it to the paginator object and to check for crazy user input: non-int values and non-existing pages are handled automatically. This appears to be compatible with DiggPaginator, also.

Cons of ListView:

  • No access to self.request (or self.session) outside of methods.
Saturnix
  • 10,130
  • 17
  • 64
  • 120
  • `self` does not exist outside of methods in any other class, not only in `ListView` – Gocht Nov 13 '15 at 19:09
  • Indeed... which is a point in favor of a normal view function, where you have easier access to context and request. Unless somebody can explain how and why we should use class views when these features are needed. – Saturnix Nov 13 '15 at 19:12
  • for example: where is the method to retrieve the request object? Should I do this in get_context_data? In that case it would be extremely unclear and subjective to anybody reading my code. Why is there no "get_request_data"? – Saturnix Nov 13 '15 at 19:14
  • I think a pro is that you can define a `get` (for listing) and a `post` method (for your filtering form) in the same view using the same url. And you can access to the request and session in both, get and post methods. – Gocht Nov 13 '15 at 19:14
  • Why would you need `self.request` outside a method? Will you write logic outside a method? You can access `request` inside any class-view's method. – Gocht Nov 13 '15 at 19:16
  • would you suggest to override the get method should my filtering form use get instead of post? I think this should be a separate question, though... Thanks for your help! – Saturnix Nov 13 '15 at 19:17
  • No, I said that you can use POST for your form and GET for your listing objects, in the same view but in separated methods (HTTP verbs) – Gocht Nov 13 '15 at 19:19
  • I understand, but the use of GET for the filtering form is compulsive for my app: I need "copypastable" links to search queries (quite a common use-case). So I was asking if overriding the GET method is considered bad-design or not (although we're going a bit off-topic)... – Saturnix Nov 13 '15 at 19:23
  • Oh, I understand. Yes I think is normal override methods GET to catch params and filter list, or you could use some external project, such as [django-filter](http://django-filter.readthedocs.org/en/latest/usage.html). But this should be another question. This is a good question and I hope to get more points of view. – Gocht Nov 13 '15 at 19:28
  • thanks for your feedback and help. With a little bit of research, I've found that overriding the get_queryset method can also be a good idea for filtering. Example: http://www.pythondiary.com/blog/Oct.31,2012/really-starting-love-djangos-class-based-views.html – Saturnix Nov 13 '15 at 19:30
  • took a break and posted a separate question: http://stackoverflow.com/questions/33701703/django-get-search-form-in-listview-class-view – Saturnix Nov 13 '15 at 21:02

0 Answers0