> > It's not a particularly bad idea; having an object carry with it > standardized information which tells you what template to use to > display it would be pretty easy (assuming, of course, that you have > the ability to lay out the model classes to support that). >
Fortunately my models make this very easy. The object is always of one general type that has a GenericForeignKey to the more specific types. My 'get_template' thus only has to appear once in the quasi-superordinate class, and can construct a template name for the 'content' (generic-related) object by using content_type. > > You could do that, by using introspection and making educated guesses > about which fields you want. Or you could try to standardize the > models up-front so that they'd all have a few common field names > (things like 'title', 'pub_date', etc.), so you'd end up doing less > introspection at runtime. > I've decided on a hybrid for now. I'll use the template_name method with a template per model class, but fall back to a generic template which attempts introspection if it isn't found (ie. if I haven't written the specific template yet). --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
