Allow callable queryset in generic views

[raffaele.salmaso@…]

I need to pass a variable queryset based on some external condition
(i.e. it can be Entry.objects.all() or Entry.objects.filter(...) or other), but with current implementation it is impossible,
because generic views want a queryset, which is set indefinitely (I'm thinking about the use in urls.py, not in
custom views).

Actually I wrote a simple wrapper, as

def obj_list(request, queryset, ...):
    if callable(queryset):
        queryset = queryset()
    return object_list(request, queryset, ...)

...

and pass a function which returns the queryset I need.

I found it could be useful if it is included directly in the generic views function.

The attached patch adds this functionality, and it doesn't break any previous code.

[andreas@…]

Is this really neccessary? Since the queryset-function is not getting access to the request, this seems to be kind of limited.

Wouldn't a custom manager method do the trick much better? For more complex computations of the queryset it would often be useful to have access to the request and likely the view arguments too, hence a wrapper would be way more useful.

See ​http://www.b-list.org/weblog/2006/nov/16/django-tips-get-most-out-generic-views/

The patch is also missing tests.

-1

[Malcolm Tredinnick]

Thanks for the patch, but we aren't going to do this. The solution to any problem involving wanting to pass some kind of customised queryset to a generic view is to create your own view that creates the right queryset and then calls the generic view.

Although each little addition to generic views only feels like a few lines, it is a few extra lines each time that requires extra maintenance, prompts extra questions on the users list, adds extra documentation, requires extra tests, etc. It basically adds to the overhead when it's a three line function when the user needs it (which usually results in cleaner code, too, since it's clear what you're trying to do).

[(none)]

Milestone post-1.0 deleted