At 08:28 AM 2/1/2006 -0500, Kevin Dangoor wrote: >On 1/31/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > Unlike Jim, I'm also actively *against* having such a spec because it > > creates the illusion that a useful problem has been solved. I don't have > > anything against the Turbo/Buffet API, mind you, I just don't want it > > anywhere near a PEP. It's a niche solution to a niche problem, which is > > allowing web frameworks to offer an illusion of choice to developers. > >There may need to be two discussions here. There are some minor tweaks >to the current TurboGears template plugin spec that people want. I >don't know how many people are using those plugins, but I do know that >there are at least three. I'm fine with taking a first step of making >our changes to the simple variable-to-string interface and having that >be a de facto standard among those of us using these plugins. > >If we can devise a standard that builds on WSGI in some useful way and >allows for more uses and wider adoption, as Phillip suggests, that >does seem like a fine goal for the web-sig. That effort is not going >to stop or hinder those of us who are already using these template >engine plugins happily, so I don't think we need to look at this as an >either-or proposition. The PEP would only cover the larger standard, >but we can still make good use of the tools we have today.
+1. I just want to make it so that frameworks get a bigger win by supporting WSGI templating than by only implementing the vars-to-strings convention, in order to encourage more frameworks to let WSGI pass all the way through their stack. This gets us a lot closer to the place where anything works from inside of anything. _______________________________________________ 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
