I'm a fan of data-driven stuff too, particularly when the data is just simple strings, lists, dictionaries and other basic Python types. I don't mind the occasional simple python: expression (especially because they're faster than path expressions), but for some reason it gives me the heeby jeebies to navigate deep persistent object hierarchies within ZPT via any kind of expression. It just seems cleaner to go get the info you need in Python and turn it into simple data structures that you can pass to the template through a method call or attribute of the view. I think one of the reasons that I dislike navigating a persistent object hierarchy is that, if I wanted to, I couldn't really defer rendering until "the last possible moment" by passing a callable that returns an iterator to, say, Medusa, in the main thread, as the database connection might already be closed and even if it wasn't, I probably couldn't use it reliably between threads. If all my data was simple data structures, I could. meld3 can (but doesn't currently, at least in the z3meld bindings) get around this problem by deferring "write_html" rendering by returning something that implemented IResult or IStreamIterator that held on to a reference to the mutated tree (which is devoid of persistent objects of any kind).

There's a small, related minor flameup on the web-sig list about this same thing at the moment mainly revolving around the question "should it be possible for template evaluations to have side effects" (like setting response headers) in the context of a "template specification". You might wanna join in the fun. I'm basically lost in that thread at the moment. Complexities abound.