Using template filters doesn't guarantee that given template is rendered in
RequestContext, not in Context. so, you still have to use threadlocal to
pass request through.
You may look at middleware framework to save request variable at threadlocal
in less dirty way. Also you may subclass template
As an aside, it seems curious to me that in a generally flexible
framework like Django a problem like this should have only a dirty
solution. I've encountered a few instances where it would be useful
to have access to request variables, but there's no way to pass them.
On Oct 13, 3:10 pm,
Definitely one possibility. I've heard threadlocals is unreliable,
though. Is that correct?
Here's another option I'm considering
Say thirdpartyview renders 'template.html'. I can write my own
template.html that looks like so:
{% extends 'template.html'|theme %}
{% block someblock %}
Seems that any solution would be dirty, so why don't you set threadlocal
variable with request and monkey-patch template loader?
On Tue, Oct 13, 2009 at 11:03 PM, Nan wrote:
>
>
> The trouble is that I've got third-party apps that have their own
> views that don't include
True. I'd like to find a solution with as few places as possible to
maintain changes, though.
> Even if you patch django and add request argument to get_template you
> also should rewrite all aplication views to push their requests into
> get_template.
>
> It's quite simple to only patch views
The trouble is that I've got third-party apps that have their own
views that don't include the template logic.
so in thirdpartymodule.views.py:
def thirdpartyview(request, vars):
# Do lots of fancy processing
return render_to_response('template.html', context)
In my project, I need a
This wouldn't work?
def view(request):
if request.user.theme = "blue":
template = "app/blue/template.html"
elif request.user.theme = "yellow":
template = "app/yellow/template.html"
return render_to_response(template)
This wouldn't work?
def view(request):
if request.user.theme = "blue":
--~--~-~--~~~---~--~~
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
2009/10/13, Nan :
>
> Making request global definitely sounds like a potentially fragile
> solution. I noticed that the template loaders take a directory list
> argument, but it doesn't seem to ever get passed in -- it's not even
> an argument for loader.get_template() or
Making request global definitely sounds like a potentially fragile
solution. I noticed that the template loaders take a directory list
argument, but it doesn't seem to ever get passed in -- it's not even
an argument for loader.get_template() or loader.select_template().
One possibility might be
Ok, moving this code to decoration function really good.
And now do you want to add this template selection logic into third-party
apps you using in this project?
I have no idea.
As i remember this is called monkey-patching
>>> import test
>>> def heh(func):
... def helper():
... print "y"
Well, I'm using a theming system -- each user can choose a theme to
use, and that choice is attached to their account. Not just the base
template but the inner templates for some parts of the site can vary
from theme to theme, so I want to run something to the following
effect:
def
You should carefully look at the code of django template loaders.
What do you mean? Dou you want template paths to be stored in the database
and dinamically change? Or do you want to use 3rd-party app but change
template dirs it is looking for?
2009/10/12 ringemup
>
> I need
I need to find a way to programmatically change the template path for
every view in my project -- a decorator seems like a nice DRY way to
accomplish that. But what's the best way to apply it to views in
third-party apps?
The only way to accomplish this that I can think of is to declare new
14 matches
Mail list logo