Re: Proposal: Add current_app to request and pass it to template loaders.

[digi604]

Was there any movement in this regard?

On Monday, March 28, 2011 2:11:42 PM UTC+2, Tai Lee wrote:
>
> On Mar 28, 4:08 pm, Justin Holmes  wrote: 
> > By "current app," do you mean the app which contains the view to which 
> > the current URL is mapped? 
>
> I mean the "namespace" (instance name) for the requested URL or the 
> "current_app" attribute of a context object which is supposed to be 
> used as a hint for reversing named URLs. I think it should also be 
> passed to template loaders as a hint, so that templates can be 
> overridden for a specific app instance. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Add current_app to request and pass it to template loaders.

[Tai Lee]

On Mar 28, 4:08 pm, Justin Holmes  wrote:
> By "current app," do you mean the app which contains the view to which
> the current URL is mapped?

I mean the "namespace" (instance name) for the requested URL or the
"current_app" attribute of a context object which is supposed to be
used as a hint for reversing named URLs. I think it should also be
passed to template loaders as a hint, so that templates can be
overridden for a specific app instance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Add current_app to request and pass it to template loaders.

[Justin Holmes]

By "current app," do you mean the app which contains the view to which
the current URL is mapped?

On Mon, Mar 28, 2011 at 12:39 AM, Tai Lee  wrote:
> Now that 1.3 is out, does any core dev have an opinion, feedback or
> suggestions on this?
>
> I've solved my immediate need with two template loaders (subclasses of
> the app_directories loader) that use thread locals. One prefixes the
> requested template name with the app name and the other prefixes it
> with the namespace.
>
> But I'd still like to see Django improved so that users can create
> template loaders which have access to the current app. It would also
> be nice for process_view middleware to have access to the other
> attributes of the ResolverMatch object (app name, namespace, etc) to
> avoid having to resolve URLs twice.
>
> Cheers.
> Tai.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Add current_app to request and pass it to template loaders.

[Tai Lee]

Now that 1.3 is out, does any core dev have an opinion, feedback or
suggestions on this?

I've solved my immediate need with two template loaders (subclasses of
the app_directories loader) that use thread locals. One prefixes the
requested template name with the app name and the other prefixes it
with the namespace.

But I'd still like to see Django improved so that users can create
template loaders which have access to the current app. It would also
be nice for process_view middleware to have access to the other
attributes of the ResolverMatch object (app name, namespace, etc) to
avoid having to resolve URLs twice.

Cheers.
Tai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Add current_app to request and pass it to template loaders.

[Dan Fairs]

Some tags you could potentially add 'hidden' values like __theme__ in
the context using RequestContext and then have the tags pass those on
to get_template(). Assuming tags played nicely and always passed along
those values to their nodelists contexts.

Other tags like {% include "app/sometemplate.html"%} get the template
at compile time of the parent template.  The compiled template might
be cached, or otherwise re-used - so that approach isn't reliable.

I hope there is a solution I overlooked.


I've implemented something similar to this without threadlocals, using 
the new class-based views infrastructure. You can override 
TemplateView.get_template_names to return an iterable of template names 
(by default it returns [self.template_name], actually defined in 
TemplateResponseMixin).


You can then vary what you return based on the request, which is 
available as an attribute of the base view class.


Cheers,
Dan

--
Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.com

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Add current_app to request and pass it to template loaders.

[Doug Ballance]

I too would very much like a request aware template loader.  For my
project the threadlocals approach was the only way I could find to
meet my requirements of a site-based template structure (project has
multitenancy) and user selectable template 'themes'.

I've tried looking at the django source to come up with a non-
threadlocals implementation, but came to the conclusion that it wasn't
easily possible without some kind of global due to the way the
templates are compiled.

Some tags you could potentially add 'hidden' values like __theme__ in
the context using RequestContext and then have the tags pass those on
to get_template(). Assuming tags played nicely and always passed along
those values to their nodelists contexts.

Other tags like {% include "app/sometemplate.html"%} get the template
at compile time of the parent template.  The compiled template might
be cached, or otherwise re-used - so that approach isn't reliable.

I hope there is a solution I overlooked.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.