Peter Rowell wrote:
>> 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.
Ok, I've learned enough to make this approach work and it is indeed easy.
But it has a small bit of inelegance...
Is it really necessary to complicate every 'view' method by appending
'context_instance=RequestContext(request)' to the render_to_response
call? This seems totally boilerplate and a violation of DRY.
>> That way lies madness (it's called PHP and ASP, amongst other nasty
>> names).
>
> Amen.
Yes. That's why we're all here.
Thanks, Malcom and Peter!
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
