- 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 middleware.
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 this
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 the
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
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 callback returned by
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 was
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 standard support
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 are
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 comes
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 thing.
[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_stream
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 templating
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
14 matches
Mail list logo
