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
--
You received this message because you are subscribed to the Google Groups
"Dja
maybe even a simple request.template_folders could do the job...
but it would work only with the new templateresponse class...
On 10 Nov, 21:23, Ric wrote:
> i agree with nan, it would be a nice feature.
>
> On 10 Nov, 21:12, Ric wrote:
>
>
>
>
>
>
>
> > > If you're using class-based views, over
i agree with nan, it would be a nice feature.
On 10 Nov, 21:12, Ric wrote:
> > 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.
--
You received
> 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.
--
You received this message because you are subscribed to the Google Groups
"Django developers" grou
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
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 c
On Thu, Nov 10, 2011 at 10:20 AM, Florian Apolloner
wrote:
> 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, p
> 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?
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 di
On Wed, Nov 9, 2011 at 7:10 PM, Doug Ballance wrote:
> 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.
>
Please no - an optional argument is all well and good, u
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.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to t
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
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
13 matches
Mail list logo
