Re: [Web-SIG] Standardized template API

2006-02-03 Thread Ben Bangert
On Feb 2, 2006, at 11:49 AM, Phillip J. Eby wrote: For frameworks like TurboGears that treat a template as a formatter of the return value of some Python code, the difference wouldn't be user-visible. And for frameworks, servers, or tools that use WSGI internally now (e.g. Paste, Routes,

Re: [Web-SIG] Standardized template API

2006-02-03 Thread Ben Bangert
On Feb 3, 2006, at 11:57 AM, Phillip J. Eby wrote: I think maybe there's some confusion here as to what I'm suggesting SCRIPT_NAME be set to. I probably should've said that SCRIPT_NAME should represent the consumed part of the URL, and PATH_INFO should be empty unless there's some

Re: [Web-SIG] Standardized template API

2006-02-03 Thread Phillip J. Eby
At 01:34 PM 2/3/2006 -0800, Ben Bangert wrote: On Feb 3, 2006, at 11:57 AM, Phillip J. Eby wrote: I think maybe there's some confusion here as to what I'm suggesting SCRIPT_NAME be set to. I probably should've said that SCRIPT_NAME should represent the consumed part of the URL, and PATH_INFO

Re: [Web-SIG] Standardized template API

2006-02-03 Thread Michael Bayer
Phillip J. Eby wrote: What I'd suggest is that this is actually an opportunity for Myghty to put its lookup and caching on one side of the interface, and an actual template rendering facility on the other side. That is, treat Myghty as an embedd*er* rather than the embedd*ee*, so that the