I've submitted a pull request (https://github.com/django/django/pull/ 51) for an active() relatedmanager method on the models class. I
wanted to get some feedback from other devs about inclusion into
trunk. I've included a patch to the docs if you want more info.
> I've submitted a pull request (https://github.com/django/django/pull/ > 51) for an active() relatedmanager method on the models class. I > wanted to get some feedback from other devs about inclusion into > trunk. I've included a patch to the docs if you want more info.
Hello,
If I understand correctly, this is same idea as #16611.
This feature was rejected by a core developer, which means it won't be added to Django.
I never saw that ticket. I've been looking at it purely from the
perspective of trying to inject it into the model in my app to get
around doing expensive filtering in my template.
I see Jacob's point that saving a few chars in python is not worth it
for the cost of having to read docs to figure out what it does, but
this would be a fantastic thing to have in templates where there is no
way to specify filtering.
> > I've submitted a pull request (https://github.com/django/django/pull/ > > 51) for an active() relatedmanager method on the models class. I
> > wanted to get some feedback from other devs about inclusion into
> > trunk. I've included a patch to the docs if you want more info.
> Hello,
> If I understand correctly, this is same idea as #16611.
> This feature was rejected by a core developer, which means it won't be
> added to Django.
On Sep 25, 8:02 am, tWoolie <thomas.woolf...@student.adelaide.edu.au>
wrote:
> I never saw that ticket. I've been looking at it purely from the
> perspective of trying to inject it into the model in my app to get
> around doing expensive filtering in my template.
> I see Jacob's point that saving a few chars in python is not worth it
> for the cost of having to read docs to figure out what it does, but
> this would be a fantastic thing to have in templates where there is no
> way to specify filtering.
The thing is that I believe django as a whole would benefit from this
kind of functionality. The whole point of custom managers is to add
functionality, not just to your app, but to every app that FKs against
your models.
In the case of contrib.auth, this functionality is really handy
spanning across related fields.
Considder the case of a template that currently looks like this:
{% for moderator in forum.moderators.all %}
{% if moderator.active %}
{{ moderator|profilelink }}{% if not forloop.last %},{% endif
%}
{% endif %}
{% endfor %}
This is an example of the template code that I add to djangobb by
overriding it's templates. djangobb currently has no custom User
subclass that it injects into it's moderator relationship, and hence i
have to do a filter in the template, or modify djangobb and give up on
getting auto updates without merging my code in every time.
If the user model had a active() or is_active custom manager method
that had use_for_related_fields set to True, then it enables you to
use a very easy syntax:
{% for moderator in forum.moderators.active %}
{{ moderator|profilelink }}{% if not forloop.last %},{% endif %}
{% endfor %}
which does efficient datbase side filtering of active/inactive
members.
This is the kind of low-hanging fruit that is EASY to implement, would
be used by plenty of people (really, how many people ever want
deactivated users showing up all over their site) and would provide
instant benifit to template writers, and specifically to people who
don't want to modify external apps to add functionality/address
deficiencies in django.
<tomasz.zielin...@pyconsultant.eu> wrote:
> I'm the author of #16611 ticket and after some consideration I also think
> that proxy models are the way to go for such customizations.
> This is an example of the template code that I add to djangobb by > overriding it's templates. djangobb currently has no custom User > subclass that it injects into it's moderator relationship, and hence i > have to do a filter in the template, or modify djangobb and give up on > getting auto updates without merging my code in every time.
> If the user model had a active() or is_active custom manager method > that had use_for_related_fields set to True, then it enables you to > use a very easy syntax:
> {% for moderator in forum.moderators.active %} > {{ moderator|profilelink }}{% if not forloop.last %},{% endif %} > {% endfor %}
> which does efficient datbase side filtering of active/inactive > members.
> This is the kind of low-hanging fruit that is EASY to implement, would > be used by plenty of people (really, how many people ever want > deactivated users showing up all over their site) and would provide > instant benifit to template writers, and specifically to people who > don't want to modify external apps to add functionality/address > deficiencies in django.
Isn't the problem here that 'forum.moderators' is returning users who are not active? djangobb should do this filtering in the objects they supply to their templates (or at least provide an alternative 'active_moderators'), because this kind of business logic decision should be made by view code, not template code.
If djangobb is wrong here, you should be filing a bug with them. If they are right, then your app is 'wrong' for overriding the business logic in a template. If both are 'right', then this is just an example of a case where a 3rd party app doesn't do exactly what you want. But there are many examples of that, and we can't build everything into Django to fix specific limitations of certain apps.
Regards,
Luke
-- "I think you ought to know I'm feeling very depressed." (Marvin the paranoid android)
