Ivan Sagalaev wrote: > Apart from these two ways of working around views there is also a > 'template context processor' thingy. It's like extra_context but not > static. It's a custom function returning context dict that is called for > every view (well not exactly every view but it doesn't matter for now, > for generic views it works). Docs are here: > http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext
I just wrestled with RequestContext to get request.session data into a template, so this is fresh on my brain. But it seems like overkill for my needs at the moment. Especially since the vars I need are only for a few templates. > To summarize. You can put your logic in urls.py, in a template tag, in a > context processor, in a wrapper around generic view or in a custom view. > What to choose is very much depends on your application and how you feel > is better. Some subtle differences that I rely on: > > - context processor is for 'global' vars that you need almost everywhere > in templates > - template tag is a more complex logic that just a vars and it also > should be useful in many templates > - extra_context is a dumb data (no logic) for configuring certain > generic views, not the whole site > - wrapper around a generic is same as extra_context but if you need some > logic > - custom view is a custom view :-) Thanks for the summary of options in adding to a template's context. I think I'll go with template_tags for this particular need. Nate. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
