Global Variables in Templates?

601 views
Skip to first unread message

niklas.voss

unread,
Oct 7, 2007, 12:21:51 PM10/7/07
to Django users
I searched around and haven't found anything about this Topic, so is
it possible to define Global Variables, which i can get in templates?

So on my site i have a couple of settings, which are most time the
same and i didn't want to send them with every new app again with
render_to_response to the template, so i wan't a file or something
were i can define this constants.

So is it possible to define Constants or Global Variables, which can i
get in every app? And is there a way to get them in the template,
without sending them with render_to_response?

thank you very much,
Niklas Voss

P.S. sorry for my bad english :(

Malcolm Tredinnick

unread,
Oct 7, 2007, 12:27:34 PM10/7/07
to django...@googlegroups.com
On Sun, 2007-10-07 at 16:21 +0000, niklas.voss wrote:
> I searched around and haven't found anything about this Topic, so is
> it possible to define Global Variables, which i can get in templates?
>
> So on my site i have a couple of settings, which are most time the
> same and i didn't want to send them with every new app again with
> render_to_response to the template, so i wan't a file or something
> were i can define this constants.
>
> So is it possible to define Constants or Global Variables, which can i
> get in every app? And is there a way to get them in the template,
> without sending them with render_to_response?

Look at TEMPLATE_CONTEXT_PROCESSORS and use RequestContext instead of
Context in your views. See [1] for lots of details. Remember to read the
note about to pass RequestContext to render_to_response().

[1]
http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext

Regards,
Malcolm

lars

unread,
Oct 8, 2007, 4:37:21 AM10/8/07
to Django users
Hi!

> Look at TEMPLATE_CONTEXT_PROCESSORS and use RequestContext instead of
> Context in your views. See [1] for lots of details. Remember to read the
> note about to pass RequestContext to render_to_response().

You mean like this:

return render_to_response('my_template.html',
my_data_dictionary,

context_instance=RequestContext(request))

I can see why it is necessary to instantiate RequestContext with the
request object. But in terms of DRY I wonder wether there isn't a
better way? I haven't looked at the sources yet so I cannot say what
is possible and what not.
Maybe RequestContext could be a member of the request object so that
the caller of the view method would be responsible for instantiating
the RequestContext. Just an idea :-)

Yours,
Lars

James Bennett

unread,
Oct 8, 2007, 5:41:06 AM10/8/07
to django...@googlegroups.com
On 10/8/07, lars <la...@woeye.net> wrote:
> I can see why it is necessary to instantiate RequestContext with the
> request object. But in terms of DRY I wonder wether there isn't a
> better way?

Sure, just write a short wrapper function which calls
"render_to_response" and uses a RequestContext. One example which you
can use is available on djangosnippets:

http://www.djangosnippets.org/snippets/3/

Having Django "automatically" do this for you would be a bad idea,
because context processors may expose information to templates that
you wouldn't want to have globally available to template authors (for
example, the "request" context processor, because it makes the full
HttpRequest available, also necessarily makes things like the user's
session -- which is an attribute of the request -- and any posted data
available).


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

lars

unread,
Oct 8, 2007, 7:57:57 AM10/8/07
to Django users
> Sure, just write a short wrapper function which calls
> "render_to_response" and uses a RequestContext. One example which you
> can use is available on djangosnippets:
>
> http://www.djangosnippets.org/snippets/3/

Ah, brilliant! Problem solved =D

> Having Django "automatically" do this for you would be a bad idea,
> because context processors may expose information to templates that
> you wouldn't want to have globally available to template authors (for
> example, the "request" context processor, because it makes the full
> HttpRequest available, also necessarily makes things like the user's
> session -- which is an attribute of the request -- and any posted data
> available).

Ok, I see and agree. Since all the templates of my application are
under my
control this aspect did not come into my mind :-)

Maybe one could post a link to this snippet in the docs? I guess I
wasn't the only
one asking for another approach?

Yours,
Lars

Malcolm Tredinnick

unread,
Oct 8, 2007, 9:51:19 AM10/8/07
to django...@googlegroups.com
On Mon, 2007-10-08 at 04:57 -0700, lars wrote:
[...]

> Maybe one could post a link to this snippet in the docs? I guess I
> wasn't the only
> one asking for another approach?

That would be overkill. This is Python. If you want a function that does
the same thing over and over again, you write one! There's nothing
special about Django here and we can't really post a link in the docs
every time somebody might want to write a function to do something.

Malcolm

Reply all
Reply to author
Forward
0 new messages