One specific concern about the "returning the published object" for publisher-based frameworks is that often the published object has references to other objects that might not make sense in the context of the thread handling the rendering of the template. For example, if you're using a thread pool behind a Twisted server, and the thing doing the rendering is in "the main thread", methods hanging off of the "published object" might try to make use of thread-local storage, which would fail. Zope 3 uses thread-local storage for request objects, IIRC.
This might be a nonissue, because I'm a little fuzzy on which component(s) actually do(es) the rendering of the template in the models being proposed. But the amount of fuzziness I have about what's trying to be specified here makes me wonder if there aren't better things to go specify. > > As I mentioned in my counter-proposal, there should probably be a > key like > 'wti.source' to contain either the object to be published (for > publisher-oriented frameworks) or a dictionary of variables (for > controller-oriented frameworks). I originally called it "published > object", but that's biased towards publisher frameworks so perhaps > a more > neutral name like 'source' or 'data' would be more appropriate. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
