New feature: Customizable get_queryset() for django.contrib.comments comment_list template tags

30 views
Skip to first unread message

Jim D.

unread,
Aug 25, 2011, 2:54:16 PM8/25/11
to django-d...@googlegroups.com
I understand that we're supposed to suggest new features here on django-dev first instead of opening a ticket, so here goes:

Presently in django.contrib.comments, there are two template tags that output a list of comments:

{% render_comment_list for [object] %}
{% get_comment_list for [object] as [varname] %}

There is a method on BaseCommentNode called get_query_set() that composes the queryset for these tags and returns it.

At present, there is no way to customize the queryset. I propose that we provided a mechanism allowing a custom comment app to define its own queryset for the list of comments that can be retrieved.

What's wrong with the present way?

* You can't use a custom manager. It assumes you want to use the manager defined on the objects attribute.
* It assumes you want at all times to apply the moderation fields if they exist.
* It doesn't allow you to define custom moderation filters, e.g. if you had a custom field with a score on your comment model and you didn't want to show comments below a threshold, or if you wanted to exclude comments that had been flagged as spam.

Is there a workaround?

You can subclass BaseCommentNode and override its get_query_set() method, and then implement your own template tags. Basically your just having to do a lot of copying and pasting to get what you need. If there is a more obvious or easy way of defining this that I have overlooked, do let me know.

Proposed feature

Two possibilities:

1. Define a new function as part of the present Custom comment app API. Call it something like get_comment_list_query_set(). Implement the present logic from the get_query_set() method there, and allow it to be overridden in the __init__.py file of the custom comment app.

2. Extend the template tag to allow a custom queryset to be passed to it. Something along the lines of:

{% render_comment_list for [object] with [custom_comment_list] %}
{% get_comment_list for [object] as [varname] with [custom_comment_list] %}

Neither of these two are mutually exclusive (i.e. they could both be implemented). I would think the second provides the most flexibility, but at the same time I think the first is in strong alignment behind the present custom comment app API philosophy.

Please let me know your thoughts/concerns/criticisms/etc. I'd be happy to work on a patch if there is consensus that it's a worthwhile idea. Thanks.
Reply all
Reply to author
Forward
0 new messages