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
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 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 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
At 05:07 PM 2/3/2006 -0800, Ben Bangert wrote:
>On Feb 3, 2006, at 3:49 PM, Phillip J. Eby wrote:
>>I don't understand what you mean by "outside of Myghty" in this
>>context. My suggestion was simply that would gain pluggability in
>>one main area: the implementation of compiling and serialization
On Feb 3, 2006, at 3:49 PM, Phillip J. Eby wrote:
> Well, somebody's got to do it. :) Not every template facility out
> there currently has any kind of location ability or caching. And
> different frameworks have their own mechanisms for locating,
> caching, etc.
True, and caching can be
At 06:08 PM 2/3/2006 -0500, Michael Bayer wrote:
>Phillip J. Eby wrote:
> > What I'd suggest is that this is actually an opportunity for Myghty to put
> > its lookup and caching on one side of the interface, and an actual
> > template
> > rendering facility on the other side. That is, treat Myghty
At 03:01 PM 2/3/2006 -0800, Ben Bangert wrote:
>On Feb 3, 2006, at 2:24 PM, Phillip J. Eby wrote:
>
>>>Wait, then how does the template engine know what template to render?
>>
>>The framework gives the engine the source of the template, and asks
>>for a WSGI app object in return. The framework is
I would add that the locating/compiling system, like Ben is mentioning,
would also need to be accessible from within the template engine; i.e.
these components need to be linkable together in recursive chains. that
is because most template engines have the ability to call sub-templates,
and this
Phillip J. Eby wrote:
> What I'd suggest is that this is actually an opportunity for Myghty to put
> its lookup and caching on one side of the interface, and an actual
> template
> rendering facility on the other side. That is, treat Myghty as an
> embedd*er* rather than the embedd*ee*, so that th
On Feb 3, 2006, at 2:24 PM, Phillip J. Eby wrote:
>> Wait, then how does the template engine know what template to render?
>
> The framework gives the engine the source of the template, and asks
> for a WSGI app object in return. The framework is allowed to hold
> on to this application objec
At 01:34 PM 2/3/2006 -0800, Ben Bangert wrote:
>On Feb 3, 2006, at 11:57 AM, Phillip J. Eby wrote:
>
>>I think maybe there's some confusion here as to what I'm suggesting
>>SCRIPT_NAME be set to. I probably should've said that SCRIPT_NAME
>>should represent the "consumed" part of the URL, and PATH
On Feb 3, 2006, at 1:34 PM, Ben Bangert wrote:
> # setup the myghty engine
> from myghty.wsgi import engine
> myghtyengine = engine(template_root='/some/path/to/templates')
>
> # render a template
> def render_myghty(template):
> environ['wti-source'] = template
> environ['wti-vars'] = m
On Feb 3, 2006, at 11:57 AM, Phillip J. Eby wrote:
> I think maybe there's some confusion here as to what I'm suggesting
> SCRIPT_NAME be set to. I probably should've said that SCRIPT_NAME
> should represent the "consumed" part of the URL, and PATH_INFO
> should be empty unless there's some
At 11:17 AM 2/3/2006 -0800, Ben Bangert wrote:
>On Feb 2, 2006, at 11:49 AM, Phillip J. Eby wrote:
>
>>For frameworks like TurboGears that treat a template as a formatter
>>of the
>>return value of some Python code, the difference wouldn't be
>>user-visible. And for frameworks, servers, or tools t
On Feb 2, 2006, at 11:49 AM, Phillip J. Eby wrote:
> For frameworks like TurboGears that treat a template as a formatter
> of the
> return value of some Python code, the difference wouldn't be
> user-visible. And for frameworks, servers, or tools that use WSGI
> internally now (e.g. Paste, Rout
At 07:07 PM 2/2/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 01:48 PM 2/2/2006 -0500, Michael Bayer wrote:
>>
>>>Can those of us who
>>>have worked less with "the high end" see some real examples of what
>>>they need, and how they will be marginalized by a template adapter
>>>API?
>>
Phillip J. Eby wrote:
> At 01:48 PM 2/2/2006 -0500, Michael Bayer wrote:
>
>>Can those of us who
>>have worked less with "the high end" see some real examples of what
>>they need, and how they will be marginalized by a template adapter
>>API?
>
>
> Have you ever used PHP? ASP? DTML? Specifica
At 01:48 PM 2/2/2006 -0500, Michael Bayer wrote:
>Can those of us who
>have worked less with "the high end" see some real examples of what
>they need, and how they will be marginalized by a template adapter
>API?
Have you ever used PHP? ASP? DTML? Specifically, have you ever used them
to gener
is it possibly of value to just put some of these ideas into practice
first without shooting any of them down ? I find it very hard to
come up with broad-ranging specs, and then declare it as "thats the
way it will be", without having a decent community of folks trying
out the ideas and se
On 2/2/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
> C'mon guys, where's the shooting down of my ideas that y'all promised? ;)
>
Bang.
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.
At 05:42 PM 2/1/2006 -0500, Clark C. Evans wrote:
>| The "template" doesn't get to control the status or headers if all it
>| can do is return is a string.
>
>WSGI the hammer! Must we necessarly have a nail here?
Who's "we"? Strings don't meet *my* use cases, or those of other template
system a
On Wed, Feb 01, 2006 at 05:15:26PM -0500, Phillip J. Eby wrote:
| The "template" doesn't get to control the status or headers if all it
| can do is return is a string.
WSGI the hammer! Must we necessarly have a nail here?
I think what's missing in this discussion is that templates are often
use
At 02:48 PM 2/1/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>My criteria is that it would be easy to implement Phillip's proposal in
>>>terms of mine (and I could provide a sample implementation of that if it
>>>would help), but it doesn't seem so easy to do the opposite.
>>
>>Actuall
Phillip J. Eby wrote:
>> My criteria is that it would be easy to implement Phillip's proposal
>> in terms of mine (and I could provide a sample implementation of that
>> if it would help), but it doesn't seem so easy to do the opposite.
>
>
> Actually, I believe you've got that backwards. Many
At 01:53 PM 2/1/2006 -0500, Chris McDonough wrote:
>One specific concern about the "returning the published object" for
>publisher-based frameworks is that often the published object has
>references to other objects that might not make sense in the context
>of the thread handling the rendering of t
At 12:29 PM 2/1/2006 -0600, Ian Bicking wrote:
>Clark C. Evans wrote:
>>On Tue, Jan 31, 2006 at 09:04:43PM -0600, Ian Bicking wrote:
>>| Phillip J. Eby wrote:
>>| >1. It disadvantages better solutions (whether frameworks or templates)
>>| >by reducing everything to the least common denominator
>>|
One specific concern about the "returning the published object" for
publisher-based frameworks is that often the published object has
references to other objects that might not make sense in the context
of the thread handling the rendering of the template. For example,
if you're using a th
On Feb 1, 2006, at 12:59 PM, Phillip J. Eby wrote:
> At 1
>
> So asking for "foo" can resolve to "foo.gif" or "foo.jpeg" in the
> file system? If you have to say in the code which it is, that's
> not what I mean.
you can write a resolver that searches the filesystem for "foo.*" and
does s
Clark C. Evans wrote:
> On Tue, Jan 31, 2006 at 09:04:43PM -0600, Ian Bicking wrote:
> | Phillip J. Eby wrote:
> | >1. It disadvantages better solutions (whether frameworks or templates)
> | >by reducing everything to the least common denominator
> |
> | I think exposing load_template is an escap
At 11:43 AM 2/1/2006 -0500, Clark C. Evans wrote:
>On Tue, Jan 31, 2006 at 08:55:22PM -0500, Phillip J. Eby wrote:
>| >>Indeed, I'd argue that it'd be better here to create a WSGI-based
>| >>template interface, rather than a specialized template interface.
>| >>That is, if the "compiled template" r
At 12:12 PM 2/1/2006 -0500, Michael Bayer wrote:
>On Feb 1, 2006, at 11:07 AM, Phillip J. Eby wrote:
>>>spec is about (like what is template polymorphism exactly ?)
>>
>>Specifying only a template's *name* in code, not its type. In
>>peak.web, if I refer to a resource or template named "foo", th
On Feb 1, 2006, at 11:07 AM, Phillip J. Eby wrote:
>> spec is about (like what is template polymorphism exactly ?)
>
> Specifying only a template's *name* in code, not its type. In
> peak.web, if I refer to a resource or template named "foo", the
> system looks in the resource directory and
On Tue, Jan 31, 2006 at 08:55:22PM -0500, Phillip J. Eby wrote:
| >>Indeed, I'd argue that it'd be better here to create a WSGI-based
| >>template interface, rather than a specialized template interface.
| >>That is, if the "compiled template" returned by a template engine is
| >>just a WSGI ap
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
At 02:03 AM 2/1/2006 -0500, 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
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,
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. I
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
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
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..
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.
>>
[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
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
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
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
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
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 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 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:
>> 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 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:
> 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
>
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
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]
> 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
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
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
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
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:
| >>
| >>*
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 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
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,
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
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
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].
>
> 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 c
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 take is a Web-Sig (and perhaps a PEP) bles
67 matches
Mail list logo
