Hi all,
Perhaps I'm doing things improperly, but a very common use case for me when
dealing with the render_template function is this:
return render_template('foo.html', form=form, user=user, bar=bar)
I pass in all of the variables that I wish to become available to the
template. As you can see, I'm just repeating myself though. It would be
super cool if I could just pass in a list or something, and the template
variable would take the name of the python variable itself.
Does anyone have any better ways of doing this? Would this be a cool
addition to Flask?
Ryan
> I pass in all of the variables that I wish to become available to the > template. As you can see, I'm just repeating myself though. It would > be super cool if I could just pass in a list or something, and the > template variable would take the name of the python variable itself. All though that might be possible by accessing the garbage collector and/or looking through the frames that is very likely to prevent an implementation with a JIT to work and way too much magic. > Does anyone have any better ways of doing this? Would this be a cool > addition to Flask? You could do ``render_template('foo.html', **locals())``, however in that case all the locals are available in the template which might cause problems if a designer uses something from the context which is not guaranteed to be there, although that's a terrible reason not use it IMHO some might think it is. I don't know if locals() affects any implementation with a JIT, however it is implicit and you should definitely read the documentation for it before using it.
On Fri, 2010-10-15 at 19:54 +0200, Daniel Neuhäuser wrote: > > > I pass in all of the variables that I wish to become available to the > > template. As you can see, I'm just repeating myself though. It would > > be super cool if I could just pass in a list or something, and the > > template variable would take the name of the python variable itself. > All though that might be possible by accessing the garbage collector > and/or looking through the frames that is very likely to prevent an > implementation with a JIT to work and way too much magic. > > > Does anyone have any better ways of doing this? Would this be a cool > > addition to Flask? > You could do ``render_template('foo.html', **locals())``, however in > that case all the locals are available in the template which might cause > problems if a designer uses something from the context which is not > guaranteed to be there, although that's a terrible reason not use it > IMHO some might think it is. > > I don't know if locals() affects any implementation with a JIT, however > it is implicit and you should definitely read the documentation for it > before using it. > > I would avoid locals() simply because it can sometimes have unexpected effects (more than polluting namespaces). However you can do something similar: context = {} context['form'] = Form(...) context['user'] = g.user context['bar'] = get_bar() render_template('foo.html', **context) You can also use context processors to DRY up some variables that are used a lot, like maybe "user" in this case.
Nitpick: the "g" variable is automatically inserted into the template, so you don't need to include g.user explicitly. On 15 October 2010 23:44, Dag Odenhall <dag.odenhall@gmail.com> wrote: > On Fri, 2010-10-15 at 19:54 +0200, Daniel Neuhäuser wrote: >> >> > I pass in all of the variables that I wish to become available to the >> > template. As you can see, I'm just repeating myself though. It would >> > be super cool if I could just pass in a list or something, and the >> > template variable would take the name of the python variable itself. >> All though that might be possible by accessing the garbage collector >> and/or looking through the frames that is very likely to prevent an >> implementation with a JIT to work and way too much magic. >> >> > Does anyone have any better ways of doing this? Would this be a cool >> > addition to Flask? >> You could do ``render_template('foo.html', **locals())``, however in >> that case all the locals are available in the template which might cause >> problems if a designer uses something from the context which is not >> guaranteed to be there, although that's a terrible reason not use it >> IMHO some might think it is. >> >> I don't know if locals() affects any implementation with a JIT, however >> it is implicit and you should definitely read the documentation for it >> before using it. >> >> > > I would avoid locals() simply because it can sometimes have unexpected > effects (more than polluting namespaces). However you can do something > similar: > > context = {} > context['form'] = Form(...) > context['user'] = g.user > context['bar'] = get_bar() > render_template('foo.html', **context) > > You can also use context processors to DRY up some variables that are > used a lot, like maybe "user" in this case. > >