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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/9-6LEMDkYqoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to