On Sun, 2010-09-19 at 19:11 -0700, Ben Bangert wrote: > On Sep 19, 2010, at 7:01 PM, Chris McDonough wrote: > > > My $.02.. if you don't have a threadlocal tmpl_context around for > > people to jam values onto/into, it'd just confuse people if the dict > > values they returned from a view weren't passed as top-level names to > > the template, and instead were made available as the subkey > > "tmpl_context". > > Well, there is a tmpl_context created on the request, that is available in > templates as well. So it is around, created per-request as in Pylons 1.0, for > ppl to add things to. So it might seem like a disconnect when someone add's > things to tmpl_context in one case, but then it gets dropped in as a template > global under the 'renderer=' scenario. Having everything a person wants to > pass in, always go in under tmpl_context seems more consistent.
Drawing an equivalence between Pylons 1 and 2 by having a request.tmpl_context seems like a bit of lose to me, because what people like about Pylons 1 tmpl_context is that they don't need to pass it around and they can just jam crap on to it from anywhere. Needing to both pass the request around as well as needing to write templates in terms of a tmpl_context seems like the worst of both worlds to me personally. What would the view return value mean in such a world? It just seems like a lot of indirection to document, and it would also mean forks of all the existing BFG templating systems. - C -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
