> There is a mechanism available
> for that -- context processors -- but people don't want to use it
> because they want *something else* that happens for every template.
Malcolm's absolutely correct: context processors (I mis-typed when I
said content processors) is exactly what you want here. They are
trivial to implement and they give you all of the global data you
could want in a template. We have about a dozen different values that
are available for each of our pages and it is all done in one routine
that is automatically called because it's in the list of
TEMPLATE_CONTEXT_PROCESSORS and we use RequestContext for pretty much
all of our views. Hey, it takes a request and returns a dict, How Hard
Could It Be? (tm)
E.g. django.core.context_processors:
def media(request):
return {'MEDIA_URL': settings.MEDIA_URL}
Put it in your TEMPLATE_CONTEXT_PROCESSORS list and now all of your
views have {{MEDIA_URL}} available to them.
> That way lies madness (it's called PHP and ASP, amongst other nasty
> names).
Amen. We have one template where we get a little nasty using a custom
tag to do arbitrary python expression evaluation mid-template, and
it's about the only template that has caused problems over time
because it Knew Too Much about too many things outside of presentation-
land. When the world changes, it breaks.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
