Please no - an optional argument is all well and good, until people
start relying on that feature. Suddenly, you then have templates that
are functionally tightly coupled to requests.
I don't get why it is difficult to extract what you want from the
request, place it in a context and render it. The OP's use case of
wanting to modify the template used can be achieved either by
calculating which template to use in the view, or by passing in the
name of the template that should be extended as a variable when
rendering.
Cheers
Tom
Please no - an optional argument is all well and good, until people
I don't get why it is difficult to extract what you want from the
request, place it in a context and render it.
If you're using class-based views, override get_templates to provide the right templates for the request.
It's not quite a tidy to handle inclusion tags though - you need to subclass django.template.base.Library, and override inclusion_tag, grabbing the request out of the context (use the 'request' context processor) - then use whatever mechanism you used before to pick a template based on the request.
Cheers,
Dan
--
Dan Fairs | dan....@gmail.com | www.fezconsulting.com
I tend to lurch from one extreme to another - I've calmed down a little now!
I worry about coupling things to the request, having used frameworks
where that has happened over time. It always leads to problems down
the line, as in my experience, a lot of what happens on a web site
happens outside of the request/response cycle.
It's already pretty hard to generate the same content outside of a
request/response if your template expects things from
TEMPLATE_CONTEXT_PROCESSORS.
Cheers
Tom