Peter Hunt wrote:
> Hi guys -
>
> I think a lot of web frameworks and applications are using a template
> engine. We should probably have an officially sanctioned templating
> engine plugin API, as it would ease adoption of existing Python web
> framework solutions.
>
> I think all it would ta
Jim Fulton wrote:
>>I think a lot of web frameworks and applications are using a template
>>engine. We should probably have an officially sanctioned templating
>>engine plugin API, as it would ease adoption of existing Python web
>>framework solutions.
>>
>>I think all it would take is a Web-Sig
On 1/30/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Peter Hunt wrote:
> > I think all it would take is a Web-Sig (and perhaps a PEP) blessing the
> > TurboGears template engine plugin API [1].
Thanks for bringing this up, Peter. Discussions to date have been ad
hoc on the TurboGears mailing list,
On 31-01-2006, Peter Hunt wrote:
> Hi guys -
>
> I think a lot of web frameworks and applications are using a template
> engine. We should probably have an officially sanctioned templating engine
> plugin API, as it would ease adoption of existing Python web framework
> solutions.
What about pep29
Kevin Dangoor wrote:
>>>Thoughts?
>>>
>>>Peter Hunt
>>>
>>>[1] http://www.turbogears.org/docs/plugins/template.html
>>
>>I concur. I've started using it in a project of mine. There's a couple
>>things I'd like to add that have come up on the TG list:
>>
>>* Add "template_file" and "template_strin
On Tue, Jan 31, 2006 at 10:48:53AM -0600, Ian Bicking wrote:
| Kevin Dangoor wrote:
| >>>[1] http://www.turbogears.org/docs/plugins/template.html
| >>
| >>I concur. I've started using it in a project of mine. There's a couple
| >>things I'd like to add that have come up on the TG list:
| >>
| >>*
On 1/31/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
That's true, but I'd caution that "it's just something you use" hides amountain of difficulties. A standard like WSGI can be relatively free in
its interface design (in order to meet a host of specialized needs),because it has a limited user grou
Ian Bicking wrote:
> Just because there is a standard doesn't mean anyone has to
> use it. I don't see why every standard has to satisfy
> everyone; if 50% of people use a standard instead of
> using framework-specific ad hoc interfaces, that's useful
> enough. Especially a standard like this wh
At 02:03 PM 1/31/2006 -0500, Clark C. Evans wrote:
>I'd stick with the notion of a "template_name" that is neither the
>template file nor the template body. Then you'd want a template factory
>method that takes the name and produces the template body (complied if
>necessary). This needs to be onc
[Clark C. Evans]
> I'd stick with the notion of a "template_name" that is neither the
> template file nor the template body. Then you'd want a template factory
> method that takes the name and produces the template body (complied if
> necessary).
I agree.
If you're looking for an existing mode
Clark C. Evans wrote:
> On Tue, Jan 31, 2006 at 10:48:53AM -0600, Ian Bicking wrote:
> | Kevin Dangoor wrote:
> | >>>[1] http://www.turbogears.org/docs/plugins/template.html
> | >>
> | >>I concur. I've started using it in a project of mine. There's a couple
> | >>things I'd like to add that have
Clark C. Evans wrote:
>
> I'd stick with the notion of a "template_name" that is neither the
> template file nor the template body. Then you'd want a template factory
> method that takes the name and produces the template body (complied if
> necessary). This needs to be once indirect since a temp
Phillip J. Eby wrote:
> At 02:03 PM 1/31/2006 -0500, Clark C. Evans wrote:
>
>> I'd stick with the notion of a "template_name" that is neither the
>> template file nor the template body. Then you'd want a template factory
>> method that takes the name and produces the template body (complied if
>
At 05:01 PM 1/31/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 02:03 PM 1/31/2006 -0500, Clark C. Evans wrote:
>>
>>>I'd stick with the notion of a "template_name" that is neither the
>>>template file nor the template body. Then you'd want a template factory
>>>method that takes the n
Phillip J. Eby wrote:
>> I believe that custom find_template implementations could handle these
>> cases. Maybe there also needs to be a relative_to_template_name
>> argument to find_template, so that it can resolve template names
>> relative to the calling template (so, for instance, you can u
At 07:20 PM 1/31/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>I believe that custom find_template implementations could handle these
>>>cases. Maybe there also needs to be a relative_to_template_name
>>>argument to find_template, so that it can resolve template names
>>>relative to
Phillip J. Eby wrote:
> At 07:20 PM 1/31/2006 -0600, Ian Bicking wrote:
>
>> Phillip J. Eby wrote:
>>
I believe that custom find_template implementations could handle
these cases. Maybe there also needs to be a
relative_to_template_name argument to find_template, so that it can
At 08:11 PM 1/31/2006 -0600, Ian Bicking wrote:
>Please, say what is wrong about the spec itself, not what is wrong about
>the scope of the spec.
The first things that come to mind are:
1. It disadvantages better solutions (whether frameworks or templates) by
reducing everything to the least co
Phillip J. Eby wrote:
> At 08:11 PM 1/31/2006 -0600, Ian Bicking wrote:
>
>> Please, say what is wrong about the spec itself, not what is wrong
>> about the scope of the spec.
>
>
> The first things that come to mind are:
>
> 1. It disadvantages better solutions (whether frameworks or template
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
OK Phillip. Time for you to put your money on the line. Give us an interface so
WE can shoot YOUR great ideas down for a change :)
~ Daniel
Phillip J. Eby wrote:
> At 08:11 PM 1/31/2006 -0600, Ian Bicking wrote:
>> Please, say what is wrong about the spec itself, not what is wrong about
>> the
On Jan 31, 2006, at 10:07 PM, Phillip J. Eby wrote:
> Subject:[Web-SIG] A trivial template API counter-proposal
> API to be provided by a "template engine":
> [...]
On Jan 31, 2006, at 10:14 PM, Daniel Miller wrote:
> OK Phillip. Time for you to put your money on the line. Give us an
At 10:28 PM 1/31/2006 -0500, James Y Knight wrote:
>On Jan 31, 2006, at 10:07 PM, Phillip J. Eby wrote:
>> Subject:[Web-SIG] A trivial template API counter-proposal
>>API to be provided by a "template engine":
>>[...]
>
>On Jan 31, 2006, at 10:14 PM, Daniel Miller wrote:
>>OK Philli
[back to the Web-SIG]
At 09:39 PM 1/31/2006 -0600, Ian Bicking wrote:
>How do you pass in variables?
environ, or a nested variable therein
> How do you get non-string output?
What kind of non-string output? For doing what?
>But there's a kind of templating that occurs in a typical applic
Phillip J. Eby wrote:
> [back to the Web-SIG]
>
> At 09:39 PM 1/31/2006 -0600, Ian Bicking wrote:
>
>> How do you pass in variables?
>
>
> environ, or a nested variable therein
OK, if you invert that (put the environ in the variables) then you
get... variables, like in the original spec.
>>
At 10:32 PM 1/31/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>[back to the Web-SIG]
>>At 09:39 PM 1/31/2006 -0600, Ian Bicking wrote:
>>
>>>How do you pass in variables?
>>
>>environ, or a nested variable therein
>
>OK, if you invert that (put the environ in the variables) then you get..
do either of these specs address the concept of componentized
templates ? that is, when you are referencing a template, compiling
its output, and delivering its textual output, in reality that
template would consist of possibly dozens of smaller sub-templates,
to form different parts of th
Michael Bayer wrote:
> do either of these specs address the concept of componentized templates
> ? that is, when you are referencing a template, compiling its output,
> and delivering its textual output, in reality that template would
> consist of possibly dozens of smaller sub-templates, t
28 matches
Mail list logo
