Django - use generic views or not?

Question

I was going through quick poll tutorial on the Django site, and the last topic is introduction of generic views. A convenient way to bypass the need of creation of custom views for every URL pattern.

This is the main idea as far as I understand:

1) Request -> URL patterns -> View -> Template

or

2) Request -> URL patterns (Generic View) [-> optional Template]

2 seems to require less code, it's only two steps as opposed to four, but on the downside you're sticking more stuff into URL patterns, there's more automagic going on, and your views are now defined in two places.

I really like the idea of having URL Patterns just that - patterns, and not adding in additional boilerplate. I also like the idea of having all Views explicitly defined, even the simple ones, so that later I know where to find them all without going back and forth through files. Plus we all know that any automagic is harder to customise than something you build from scratch (at least from Django scratch).

Am I missing something? Am I doing a big mistake that will haunt me later of I don't use generic views at all?

score 10 · Accepted Answer · edited Sep 18 '12 at 18:19

10

The intention of Generic Views is to reduce boilerplate code when you repeatedly use similar code in several views. You should really use it just for that. Basically, just because django allows something you are doing generically you shouldn't do it, particularly not when your code becomes not to your like.

If you are using django-1.3's Class Based Views, instead of passing many variables to the function in urls.py, you can override respective methods of interest, which provides the best of both worlds. - Less code, and more control.

edited Sep 18 '12 at 18:19

Ondrej Slinták

31,386
20
94
126

answered Jun 26 '11 at 17:11

lprsd

84,407
47
135
168

+1: I've found that generic views work for very specific types of URL-to-page mappings. Not surprisingly, these tend to be newspaper (and blog) oriented. – Peter Rowell Jun 26 '11 at 22:05
@PeterRowell are you saying there is some type of URL that it doesn't generic views don't "work" for? if so, can you provide an example? – Dolph Oct 13 '11 at 04:08
1

@Dolph: sort of. There is a certain "structure" to URLs that generic views work for, but I have had 2 clients where their idea of a URL differed from what the generic was capable of capturing/delivering. It;s very site-specific. – Peter Rowell Oct 13 '11 at 04:22
@PeterRowell I still don't understand how the view architecture would impact the structure of your URL's -- example?? – Dolph Oct 14 '11 at 21:19
@Dolph: the specific example I was thinking of was where the client wanted URLs based on the title of an article (nested in psuedo categories), even if the title/category had changed over time. There is nothing (that I am aware of) in the generic views architecture that addresses this type of use -- certainly nothing as of 10/2007 when the site was launched. Since then I have had 2 other clients with similar requirements. This is more of a CMS view of pages than a date/slug view, so to speak. – Peter Rowell Oct 15 '11 at 06:03
@Peter Rowell: Ah, that makes sense! *Class-based* generic views would handle that quite gracefully - just override get_object() in a DetailView... and actually, if the slug is unique, the necessary behavior is already built-in. I imagine the function-based generic views *would* be rigid in that regard. – Dolph Oct 18 '11 at 13:57

score 3 · Answer 2 · answered Jun 26 '11 at 16:29

Whether to use generic views or not is your prerogative. It won't cause you any trouble, although you might find yourself coding repetitious view logic. You might consider using wrapped/subclassed generic views in your views.py (frequently you'll want to customize them anyways), which would keep the boilerplate out of your urls.py and all the views in the same place.

score 2 · Answer 3 · answered Jun 26 '11 at 20:40

In django 1.2 I use generic views but inside a "normal" view , not in urls, like :

#views.py
import generic_views

def my_generic_list(request):
    qs = Something.objects.filter(some arguments)
    return generic.object_list(queryset = qs, ... other stuff, usually extra_context)

this way (imo) the view is very simple yet can become a "real one" in case of changes, while the urls.py remain clean

Django - use generic views or not?

3 Answers3