natebeaty wrote: > ..but apparently this will only populate the tags once, when I start up > Django, correct? Do I need to add the extra_context in a wrapper around > a generic view in views.py? Or would something like this be best > implemented as a template_tag? > > Am I correct in assuming it would be best to use a template_tag if it's > needed across many views, but otherwise easier to just populate the > template w/ extra_context?
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 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 :-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
