On Sun, Sep 19, 2010 at 7:01 PM, Chris McDonough <chr...@plope.com> wrote: > On Sun, 2010-09-19 at 18:36 -0700, Ben Bangert wrote: >> Yea, we're going to have to compose copy/paste to an extent, from the >> other docs. > > I've indicated to Ben that I am willing to genericize the BFG docs to > some extent by not linking to internal stuff in API documentation > needlessly. But I doubt this will really do much good; there are places > where those kinds of links are just required. It will probably boil > down to everything needing to be cutnpasted.
Most of the other Pylons dependencies are pretty solidified so they shouldn't change much, and when they do it's some obscure feature rather than the basic Pylons API. For BFG, we'll have to see how the documentation comes out, how much of it refers to things that are changing. As long as you're aware of which parts of the API the Pylons docs cover, it should be pretty easy to remember, "This part affects the Pylons docs." Especially as we'll be covering only a Pylons-typical application, and referring directly to the BFG docs for anything beyond that. >> On a side-note, when using the "renderer=" approach to rendering a >> template, the dict results go into the template global namespace.... >> should they instead go into tmpl_context? > > 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". > > - C The best solution is a config flag. There's precedent for this in ``config['pylons.strict_tmpl_context']``. There's a conflict between the Pylons tradition, where all variables passed to templates are exposed under 'c', and the TurboGears tradition, where they're exposed at the top level. We can't just throw the Pylons tradition under the bus, especially because it would force people to rewrite their templates for no obvious benefit. It could copy the variables to both places by default, but have a flag to put them either at the top level or under 'c'. -- Mike Orr <sluggos...@gmail.com> -- 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.
