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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
