Strategy for maintaining complex filter states?

Question

I need to maintain a list of filtered and sorted objects, preferably in a generic manner, that can be used in multiple views. This is necessary so I can generate next, prev links, along with some other very useful things for the user.

Examples of filters:

field__isnull=True
field__exact="so"
field__field__isnull=False

Additionally, after the filtered query set is built, ordering may be applied by any of the fields.

My current solution is to use a FilterSpec class containing a collection of filters, along with an initial query set. This class is then serialized and passed to a view.

Consider a view with 25 dynamically filtered items. Each item in the view has a link to get a detailed view of the item. To each of these links, the serialized FilterSpec object of the current list is appended. So you end up with huge urls. Worse, the same huge filter is appended to all 25 links!

Another option is to store the FilterSpec in the session, but then you run into problems of when to delete the FilterSpec. Next you find all your views getting cluttered with code trying to determine if the filter should be deleted in preparation for a new list of objects.

I'm sure this problem has been solved before, so I'd love to hear other solutions that you guys have come up with.

Answer 1

Depending on what you want to do, you'll want to either create a custom manager or add a new manager method.

In this example, you add a new manager that selects blog posts that are marked as published with a date after the current datetime.

from django.db import models
from datetime import datetime

class PublishedPostManager(models.Manager):
    def get_query_set(self):
        return super(PublishedPostManager, self).get_query_set().filter(published=True, time__lt=datetime.now())

class Post(models.Model):
    title = models.CharField(max_length=128)
    body = models.TextField()
    published = models.BooleanField(default=False)
    time = models.DateTimeField()

    objects = models.Manager() # Needed to ensure that the default manager is still available
    published = PublishedPostManager()

Then, instead of Post.objects.all(), you can use Post.published.all() to fetch all records. The normal QuerySet methods are available as well:

Post.published.count()
Post.published.select_related().filter(spam__iexact='eggs')
# etc

And of course, you can still use the default manager:

Post.objects.all()

Answer 2

You've identified the two options for maintaining user-specific state in a web application: store it in cookies/session, or pass it around on URLs. I don't believe there's a third "silver bullet" waiting in the wings to solve your problem.

The URL query-string option has the advantage that a particular view state can be bookmarked, sent as an emailed URL, &c. It also may keep your view code a bit simpler, but at the cost of some extra template code to ensure the proper query-string always gets passed along on links.

In part your preferred solution may depend on the behavior you want. For instance, if a user bookmarks (or emails to a friend) the URL for a detail view of an item, do you want that URL to simply refer to the item itself, or to always carry along information about what list that item came out of? If the former, use session data. If the latter, use URLs with query strings.

In either case, I'm confident that the code that you find "cluttering all your views" can be refactored to be elegant, DRY, and as invisible as you want it to be. Decorators and/or class-based views might help.