[Phillip]
> API to be provided by a "template engine":
>
> compile_string(text), compile_stream(input_stream) - return a WSGI
> application object for the template described by the text or file-like object
>
> write_compiled(app, output_stream) - save the compiled form of the template
> to output_s
On Feb 3, 2006, at 7:40 PM, Phillip J. Eby wrote:
> The problem for me is, I was hoping we would end up defining a
> manager->compiler interface and a publisher->resource interface
> rather than a publisher->manager one. Then again, maybe we should
> define both, and let people plug things
On Feb 4, 2006, at 8:17 AM, Guido van Rossum wrote:
> I am probably missing something, but shouldn't there also be an API to
> render the template to a string or stream given some context of
> variable names? I'm looking at this from a very different perspective,
> namely *using* various templatin
At 08:17 AM 2/4/2006 -0800, Guido van Rossum wrote:
>[Phillip]
> > API to be provided by a "template engine":
> >
> > compile_string(text), compile_stream(input_stream) - return a WSGI
> > application object for the template described by the text or file-like
> object
> >
> > write_compiled(app, o
At 09:31 AM 2/4/2006 -0800, Ben Bangert wrote:
>On Feb 3, 2006, at 7:40 PM, Phillip J. Eby wrote:
>>But it seems a little ugly to me to cram another key into environ
>>to tell the manager what template to use, when you could just have
>>a 'get(template_id)' call that gets you the WSGI app to use.
On Feb 4, 2006, at 10:55 AM, Phillip J. Eby wrote:
> But that's the case that threw this whole thing off track to begin
> with, because you can only pass in a find_template if *you're the
> template manager*. In the interface we're currently discussing,
> finding templates is internal to th
At 11:37 AM 2/4/2006 -0800, Ben Bangert wrote:
>I think the main reason Ian suggested it was because he wanted to
>implement his own lookup scheme to find templates. As I mentioned
>above, this begins to take us to the internals so I'm inclined to
>agree that its not going to help here.
Actual
Phillip J. Eby wrote:
>> Perhaps wsgiref
>>should go into the Python 2.5 standard library?)
>
>
> Sure. I'd suggest that we might want to expand it a little to include some
> of the fine contributions of other authors, such as Ian's "lint" middleware
> (which sits between an app and a server a
Well, here's the proposal I had before, tweaked slightly. This is
mostly like the TG/Buffet API, but with find_resource extracted. I
realize this is the basis of the whole WSGI offshoot before, and maybe
an API without that would be useful or easier to implement. But it
would also be way mor
On Feb 4, 2006, at 6:07 PM, Ian Bicking wrote:
>
I thought the entire point of the development of a better packaging
system (eggs) is so that not everything needs to go into the standard
library.
James
___
Web-SIG mailing list
Web-SIG@python.org
We
On 2/4/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
> >> Perhaps wsgiref
> >>should go into the Python 2.5 standard library?)
> >
> > Sure. I'd suggest that we might want to expand it a little to include some
> > of the fine contributions of other authors, such as Ian's "lint
> >I am probably missing something, but shouldn't there also be an API to
> >render the template to a string or stream given some context of
> >variable names? I'm looking at this from a very different perspective,
> >namely *using* various templating engines from an app that otherwise
> >doesn't u
Guido van Rossum wrote:
>>I think a WSGI-based HTTP server is fairly easy to stabalize. Clark
>>Evans contributed a server based on SimpleHTTPServer, which I think is
>>both pretty complete and doesn't do anything besides HTTP serving (e.g.,
>>no static file serving):
>>http://svn.pythonpaste.org/
At 04:20 PM 2/4/2006 -0800, Guido van Rossum wrote:
>ISTM that wsgiref itself
>is stable enough, and having it in the stdlib would lower the bar for
>anybody to develop WSGI-compliant apps even if they refuse to use a
>toolkit. A lot of the other things you're mentioning above seem to be
>of a diff
I think CherryPy's WSGI server should go in: it's stable, and the best-performing WSGI HTTP server out there.Peter
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options
15 matches
Mail list logo
