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.