Re: Adding more data to Generic Views

On Wed, Aug 1, 2012 at 12:43 AM, Melvyn Sopacua <m.r.sopacua@gmail.com> wrote:

On 31-7-2012 6:17, Lachlan Musicman wrote:

> I have Person, Certificate, Job and Compensation objects. The last three
> all
> have an FK (or M2M) back to a (or some) Person(s).
>

So reverse relations.

Yep, thanks - with Django I often find I have an idea in my head but don't know what to call it - and it's often surprising what the developers do call it, until it makes perfect sense . I'm still waiting for that eureka moment with reverse urls tbh - I have read the docs on those a dozen times, and just do not get why they are useful or when you would use them. I guess I need a local example.

 

>     def get_context_data(self,**kwargs):
>         #Call the base implementation first to get a context
>         context = super(PersonDetailView, self).get_context_data(**kwargs)
>         #Add in a querysets
>         context['job_list'] = Vacancy.complete.all()
>         context['certificate_list'] = Certificate.objects.all()
>         context['claim_list'] = Compensation.objects.all()

You don't need any of these. In your template, simply call:
{{ person.certificate_set.fieldname }}

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 %}

        <h3>Jobs Applied For</h3>

        {% for job in person.jobs.all %}

        <p>

        <a href="{{ job.get_absolute_url }}">{{ job.title }}, <em>{{ job.organisation }}{% if job.division %}, {{ job.division }}{% endif %}</em></a>

        </p>

 

Which gives me the problem that I was *actually* trying to solve - how to only render "Jobs Applied For" - the reason for the if statement - if jobs have been applied for by that person. It didn't work. 

I will try using person.vacancy_set.all now ...

 

If you insist on having them available as you do above, they should be:
context['job_list'] = self.get_object().vacancy_set.all()
context['certificate_list'] = self.get_object().certificate_set.all()
context['claim_list'] = self.get_object().compensation_set.all()

Required reading: 
https://docs.djangoproject.com/en/1.4/ref/models/relations/

Also, skipping the tutorial is not recommended:
<https://docs.djangoproject.com/en/1.4/intro/tutorial03/#use-the-template-system>

I didn't, but I did only skim it, since I've done it before.

> Of course, the other thing that I can't help but thinking is that at this
> point, the non-generic-view method of urls/views might be a simpler way to
> go. While Generic Views are quite versatile,  is there a point at which
> they are considered to restricting?

*too*

 

Not really. The only thing that bugs me about them is that adding extra
context requires sub-classing so you end up with a views.py that solely
consists of sub-classed generic views with 3 lines of get_context_data().

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?

anyway, thanks for hte help

L.

 

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.