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. For what it's worth, we tend to keep extremely detailed change logs in BFG. When I change documentation, I make a note about which docs I changed. As a result, while it won't be falling-off-a-log easy to keep cutnpasted Pylons docs in sync with the BFG docs, and it will require a lot of effort, it should at least be theoretically possible if someone pays attention to the BFG changelogs, and I'm more than willing to help explain changes in detail to whomever is assigned that job. > 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 -- 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.
