On 31-7-2012 22:45, Lachlan Musicman wrote:

> Yes, I was doing that originally (when there was no Compensation objects),
> but I was struggling with only rendering when a set existed - for example,
> in my person_detail.html I was rendering from the wrong direction - via the
> non-Person object via "related name" fields on the FK.
> 
>         {% if person.jobs %}

{% if person.jobs.count %}

person.jobs always exists as it is the related manager. If count is zero
the if statement resolves to false.

> Ok, thanks. I'm still confused about the usefulness of subclassing, given
> that object_set exists? I presuming it's to have the actual objects in the
> context, not just a reference to them?

No, it's primarily useful to provide data that have no relation to the
model you're presenting. Like "today's shoe discounts" displayed on the
"blue women pants" page are unrelated models (from a technical
perspective ;) ).
Another example is if you want to pass some parameters by query string
to only a few pages, but otherwise in the site don't use the request
context processor [1]:

def get_context_data(self, **kwargs) :
        context = super(MyView, self).get_context_data(**kwargs)
        context['qs'] = self.request.GET
        return context

[1]
<https://docs.djangoproject.com/ref/templates/api.html#subclassing-context-requestcontext>
-- 
Melvyn Sopacua

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to