On Monday 13 February 2006 17:29, Adrian Holovaty wrote:
> As for renaming all() to cached() and/or making SomeModel.objects a
> QuerySet directly and having to deal with cached vs. non-cached query
> sets -- we've already had this discussion, decided on it and moved
> on. It's SomeModel.objects.all(), and there's no having to mess with
> cached vs. non-cached query sets. The way it's currently handled in
> magic-removal is great, and a fine improvement. Let's move forward.
I think the discussion we had before centred on Article.objects.all()
(i.e. Managers), but the discussion I brought up again was specifically
to do with RelatedManagers (it then digressed into Managers in
general). Specifically, I now have this in some of my templates (my
app has 'camps' which have zero or more 'leaders'):
{% for leader in camp.leaders.all %}
<li>{{ leader.name }}:<br/>
{{ leader.info|escape|linebreaksbr }}</li>
{% endfor %}
Before I had this:
{% for leader in camp.get_leader_list %}
<li>{{ leader.name }}:<br/>
{{ leader.info|escape|linebreaksbr }}</li>
{% endfor %}
My point was I don't think this is a 'fine improvement' from a template
author's point of view - it's a definite step backwards IMO (and
s/all/cached would be just as bad, if not worse), especially
considering the docs that are available in 'admin/doc/models/', which
gave you everything you needed to know before. No other lists of
objects that are populated into the context will work like this (e.g.
objects which doesn't come from the ORM, or ORM objects with a property
that returns some custom list), it's just a wart of implementation that
the template authors shouldn't have to see. And there isn't a
technical reason for it either - it should be relatively easy to make
it go away.
Luke
--
Life is complex. It has both real and imaginary components.
Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
