TemplateResponse and loader should handle request

74 views
Skip to first unread message

Ric

unread,
Nov 6, 2011, 2:32:26 PM11/6/11
to Django developers
request.url_conf has been added with django 1.3.

in my opinion, the loader object should handle the request, so that
can be sublassed to pass different template folder based on request
params.

i need this feature for my app, is it possible to have different
template folder based on request params with the current django
release?

Florian Apolloner

unread,
Nov 9, 2011, 5:45:59 AM11/9/11
to django-d...@googlegroups.com
The template loader shouldn't care about the request; that would be to tightly coupled. The only thing I could think of would be to add **kwargs support to the loader functions so one could indeed pass arbitrary data done the road… This way one could write a TemplateLoader acting on request if it's in kwargs and fallback to whatever if it's not there.

Just my 2 cents,
Florian

Doug Ballance

unread,
Nov 9, 2011, 2:10:52 PM11/9/11
to Django developers
I very much like the idea of an optional keyword argument and
fallback. The template loader is one of the few places I've been
forced to use threadlocals to get get the job done.

Tom Evans

unread,
Nov 10, 2011, 4:43:01 AM11/10/11
to django-d...@googlegroups.com

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

Florian Apolloner

unread,
Nov 10, 2011, 5:20:44 AM11/10/11
to django-d...@googlegroups.com
Hi,


On Thursday, November 10, 2011 10:43:01 AM UTC+1, Tom Evans wrote:
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.

I think you missunderstood me, I didn't ment to add a optional keyword argument like request, but pass **kwargs down the chain -- The current template loaders would just ignore it completly but users might override it to supply extra data to their template loader. Either way it was just a suggestion and I am not really sold on it either…

Cheers,
Florian
 

Dan Fairs

unread,
Nov 10, 2011, 5:28:06 AM11/10/11
to django-d...@googlegroups.com
> in my opinion, the loader object should handle the request, so that
> can be sublassed to pass different template folder based on request
> params.
>
> i need this feature for my app, is it possible to have different
> template folder based on request params with the current django
> release?


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


Tom Evans

unread,
Nov 10, 2011, 6:27:41 AM11/10/11
to django-d...@googlegroups.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

Nan

unread,
Nov 10, 2011, 2:11:23 PM11/10/11
to Django developers

It would be really nice to be *able* to create a template loader that
can use the request object. If, for instance, you have a site that
needs to be able to change the template used based on user preferences
or based on the current Site object, it's a lot cleaner to be able to
do that once in a custom template loader than to have to write (or
inherit) that into every single view -- especially once you start
integrating third-party apps with their own not-necessarily-class-
based views.

Ric

unread,
Nov 10, 2011, 3:03:16 PM11/10/11
to Django developers
the first thing i have thought was that "loader shouldn't care about
the request"

but, request could be an optional argument, that can be none, with
this simple thing i can create a custom template loader, and add
whatever folder i want, based on request.

it's a way to customize a Site. i manage different site and i would
like to have a different template folder for each site, template
folder that can be different even for country or language, a lot of
things that can be extracted from request.

Ric

unread,
Nov 10, 2011, 3:12:36 PM11/10/11
to Django developers
> If you're using class-based views, override get_templates to provide the right templates for the request.

i would like a django-wide feature, to customize admin folder and
third party app.

Ric

unread,
Nov 10, 2011, 3:23:41 PM11/10/11
to Django developers
i agree with nan, it would be a nice feature.

Ric

unread,
Nov 10, 2011, 3:25:34 PM11/10/11
to Django developers
maybe even a simple request.template_folders could do the job...
but it would work only with the new templateresponse class...

ptone

unread,
Nov 12, 2011, 12:42:08 AM11/12/11
to Django developers
Just wanted to point those in this thread to this ticket:

https://code.djangoproject.com/ticket/17093

Such a refactor of the template system as outlined could eventually
incorporate some of these ideas.

-Preston
Reply all
Reply to author
Forward
0 new messages