I need to add content_type.
On Sep 20, 5:19 am, Chris McDonough <chr...@plope.com> wrote: > 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.
