views:

302

answers:

4

I'm gonna try and simplify this as much as possible. Lets say i have the following:

models.py

class Person(models.Model):
    name = models.CharField(max_length=255)

    def getRealPerson(self):
        # is there a better way to do this?
        ret = None
        try:
            ret = self.worker
        except:
            try:
                ret = self.retired
            except:
                ret = self
        return ret
class Worker(Person):
    salary = models.IntegerField(default=0)

class Retired(Person):
    age = models.IntegerField()

The example doesn't really matter for what I want, just go with me here. The purpose of this is so I can have a master Person table to reference all people.

Ideally I want to be able to call a view of Person's and have each ones specific details listed in a custom way for each class type. I'd like to use a custom inclusion_tag to do this.

people.html

{% load people_extras %}
{% for person in people %}
   {% show_person person %}
{% endfor %}

people_extras.py - templatetags

from django import template

@register.inclusion_tag('worker.html')
def show_worker(person):
    return {'person':person}

@register.inclusion_tag('worker.html')
def show_retired(person):
    return {'person':person}

#How do I write this function and use it as the show_person person tag?
from project.app.models import Worker, Retired
def show_person(person):
    person = person.getRealPerson():
    if isinstance(person, Worker):
        return show_worker # yes, this doesn't work.

I have no idea how to get it to call the correct template based on the person type.

I couldn't figure out how to accomplish this with the template using {% ifequal %} like this:

{% ifequal person.getRealPerson.__class__.__name__ "Worker" %}
    {% show_worker %}
...

I went the route I wrote above with the templatetags. However, I dont know where to put the logic to determine the person type!

I think eventually I'd like to be able to use a generic view for this as well on the Person object.

If there's a far better way to do this, I'm open to suggestions, I just want to get it working.

I've been kinda stuck here for over a day... could really use a push.

+2  A: 

Take advantage of Django's contenttypes framework to identify your model types.

See this snippet: Child aware model inheritance and use Carl Meyer's suggestion in the comments (wrap the assignment in "if not self.id:")

Van Gale
Or see this answer: http://stackoverflow.com/questions/929029/how-do-i-access-the-child-classes-of-an-object-in-django-without-knowing-the-name/929982#929982
Carl Meyer
Also note that rix fixed his snippet based on my suggestion, so it's no longer necessary to point out the comment.
Carl Meyer
Oh duh, I was at the tail end of an all-nighter and for some reason my brain wasn't registering self.pk is self.id :)
Van Gale
A: 

I use a method that I hacked together quickly at the moment to do a very similar job. I have many models inheriting from a main "base" model - to I can access everything in my database by a unique code (we call it a "go code"). To find out the child of the parent object, I do something like this:

def get_child_types(self):
    return [ c.__name__.lower() for c in self.__subclasses__() ]

def get_child(self):
    for type in self.get_child_types():
        try:
            o = self.__getattribute__(type)
        except:
            pass
        else:
            return o

I know it's messy, but it works fine. I store the object's "type" in a denormalized field in the parent object model, so I only ever have to "find" it once - which reduces the hits on the database and the CPU work required. I then just override save() to find the object type on creation, and store it in that field.

Hope it helps!

Rob Golding
This has the general right idea, but it's more complicated (and slower) than it needs to be. At creation time you already know the proper type, so you don't ever need to find it by looping through a list of types and checking each one. See http://stackoverflow.com/questions/929029/how-do-i-access-the-child-classes-of-an-object-in-django-without-knowing-the-name/929982#929982
Carl Meyer
A: 

Use this snippet for your getRealPerson() Person model method:

def getRealPerson(self):
    from django.db.models.fields.related import OneToOneRel
    from django.core.exceptions import ObjectDoesNotExist
    for related in self._meta.get_all_related_objects():
        rel_opts_name = related.get_accessor_name()
        if isinstance(related.field.rel, OneToOneRel):
            try:
                sub_obj = getattr(self, rel_opts_name)
            except ObjectDoesNotExist:
                pass
            else:
                return sub_obj

It will return you the first related object (either a Worker or a Retired).

nabucosound
+4  A: 

See this answer for an efficient way to get the right person type sub-object after querying on the Person table.

Once you have that working, you should be able to eliminate most of the complexity in your template tags by using polymorphism. If you want to display each person type using a different template, make that template name a class attribute of the model, or even just make the template name based on the model name (using person._meta.module_name). One simple template tag should then be able to cover all cases without even knowing any details of which subclasses exist. EDIT This single tag can't be registered using the inclusion_tag decorator, because you'll need to determine the template name dynamically. But it's easy to write using the simple_tag decorator:

@register.simple_tag
def show_person(person):
    t = template.loader.select_template(["%s.html" % person._meta.module_name,
                                         "person.html")
    return t.render({'person': person})

This will render a Worker using worker.html, a Retired using retired.html, etc. If the specific template for the subtype is not found, it falls back to the default person.html.

Carl Meyer
I'm a little confused on the custom template tag implementation of this. testperson.cast() returns the correct sub-object, but how can I use that in calling the correct inclusion_tag. The way I have it setup above, show_person has no way of being called (it's not registered).
lostincode
That's what I addressed in the second paragraph. Edited to hopefully make it clearer.
Carl Meyer