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_stream
read_compiled
[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 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
> >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]
> I see. But doesn't this still tie the templates API rather strongly to
> a web API? What if I want to use a template engine to generate
> spam^H^H^H^Hpersonalized emails? Or static HTML pages that are written
> to the filesystem and then served by a classic Apache setup? Or
>I see. But doesn't this still tie the templates API rather strongly to
>a web API? What if I want to use a template engine to generate
>spam^H^H^H^Hpersonalized emails?
Then set the content-type to message/rfc822. ;)
> Or static HTML pages that are written
>to the filesystem and then served
At 01:28 PM 2/5/2006 +, Alan Kennedy wrote:
>I've been dismayed over the last few days trying to follow the direction
>of this thread: it appears to me that something very simple has now
>become very complex.
On the contrary, the situation is and always has been very complex. It
only appears
[Me]
> > Or static HTML pages that are written
> >to the filesystem and then served by a classic Apache setup? Or source
> >code (program generators are fun toys!)?
[Phillip]
> Use the output file's write() method as the "write" callback returned by
> start_response(), or use one of the wsgiref h
At 10:40 AM 2/5/2006 -0800, Guido van Rossum wrote:
>[Me]
> > > Or static HTML pages that are written
> > >to the filesystem and then served by a classic Apache setup? Or source
> > >code (program generators are fun toys!)?
>
>[Phillip]
> > Use the output file's write() method as the "write" callb
On Feb 5, 2006, at 10:40 AM, Guido van Rossum wrote:
> I didn't see an output file in the proposed standard. All I saw was a
> WSGI interface. The output file is a figment of your implementation.
The WSGI interface indicates that the WSGI app will return its output
as an iterable. While WSGI wa
[Phillip J. Eby]
> Developing WSGI was not easy, either, as I'm sure you recall.You and I
> certainly argued a bit about iterators and file-like objects and such,
> and it took a while before I understood all of your use cases and we
> were able to resolve them in the spec. If you had given up
> # Or use Kid:
> kidengine = KidTemplate(**kid_args)
> content, headers = kidengine('some.template.kid', wsgi=False)
>
> # web
> return kidengine(environ, start_response)
>
> Or if people don't like relying on the object to determine if there's
> a keyword with wsgi = False,
>
> content, headers =
Phillip J. Eby wrote:
>>This topic started with Buffet, the de-facto standard templating API for
>>CherryPy. Buffet is just about textual templating, which is a good
>>thing. That's why it's very simple, and is thus actually being used.
>
>
> Which is precisely why we don't need to rush into bles
Phillip J. Eby wrote:
>>It is my strong preference that the standard API we are attempting to
>>design here does *not* tie you strongly to WSGI or the generation of
>>dynamic web content.
>
>
> That seems to be a popular position, to be sure. However, since there is
> already a de facto standar
Ben Bangert wrote:
>># Or use Kid:
>>kidengine = KidTemplate(**kid_args)
>>content, headers = kidengine('some.template.kid', wsgi=False)
>>
>># web
>>return kidengine(environ, start_response)
>>
>>Or if people don't like relying on the object to determine if there's
>>a keyword with wsgi = False,
>
At 03:26 PM 2/5/2006 -0600, Ian Bicking wrote:
>Even the most trivial of web applications needs templates to include
>other templates, so the fact that this doesn't do anything to aid or
>specify that makes the spec feel leaky. I can indicate where the
>template comes from initially, but all bets
At 02:36 PM 2/5/2006 -0600, Ian Bicking wrote:
>I think very minor fixes could improve it -- for instance, allow
>template_filename as an argument instead of only template_name. Then at
>least simple template filling would be handled well (e.g., enough for
>Paste Script), though it is unlikely
Phillip J. Eby wrote:
> At 03:26 PM 2/5/2006 -0600, Ian Bicking wrote:
>
>> Even the most trivial of web applications needs templates to include
>> other templates, so the fact that this doesn't do anything to aid or
>> specify that makes the spec feel leaky. I can indicate where the
>> template
On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> * There was an ad hoc standardization happening with TG and Buffet.
>
> * Other people were becoming interested.
>
> * Discussion was happening on the TG list, where most people on the TG
> list were not particularly interested about this sort of
On Feb 5, 2006, at 5:33 PM, Phillip J. Eby wrote:
> As Ben has previously pointed out, systems like Myghty are going to
> ignore
> your 'find_template()' because they do their own finding. So the
> spec will
> leak no matter what, until we get to the level of specification
> called for
> b
Michael Bayer wrote:
> Im not totally following every detail of this discussionbut correct
> me if I'm wrong, if we are just talking about a specification of how
> the various components of a template engine are to look and interact
> with each other, there is no reason Myghty's resolver
Ian Bicking wrote:
>> I would say that
>> the argument or arguments passed to find_template() need to be pretty
>> open ended, since you cant predict what kinds of things might be
>> meaningful to a template finder, such as in myghty's case, the resolver
>> wants to know if you are asking for t
On Feb 5, 2006, at 11:32 PM, Guido van Rossum wrote:
> Phillip described the workflow for Django/Cheetah style templates
> as follows:
>
>> * framework calls some Python code you wrote
>> * your code returns a dictionary of values you want rendered
>> * framework passes your returned values to t
Michael Bayer wrote:
> Ian Bicking wrote:
>
>>>I would say that
>>>the argument or arguments passed to find_template() need to be pretty
>>>open ended, since you cant predict what kinds of things might be
>>>meaningful to a template finder, such as in myghty's case, the resolver
>>>wants to kno
On Feb 6, 2006, at 9:16 PM, Ian Bicking wrote:
>
> The inversion of control is the tricky part. In something like
> Cheetah, Kid, or ZPT the template (as represented solely by the
> file contents) gets control first, and then explicitly hands it off
> to whatever it is "inheriting" from (t
-> > 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 and checks both for compliance) and
-> > maybe even his "Python debugger in the browser" mid
27 matches
Mail list logo
