User.objects.active() support.
tWoolie
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.
Aymeric Augustin
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.
The rationale is explained in
https://code.djangoproject.com/ticket/16611#comment:5
Thanks for the suggestion!
--
Aymeric Augustin.
tWoolie
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.
On Sep 23, 9:26 pm, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> 2011/9/23 tWoolie <thomas.woolf...@student.adelaide.edu.au>:
> > 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.
>
Prometheus
wrote:
> 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 believe for this purpose, the Proxy models feature would be the
perfect solution, please see: https://docs.djangoproject.com/en/1.3/topics/db/models/#proxy-models
Tomasz Zielinski
tWoolie
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.
On Sep 28, 5:48 pm, Tomasz Zielinski
Luke Plant
> 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)
Luke Plant || http://lukeplant.me.uk/