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, Routes,
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 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_INFO
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 the
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
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?
Have you ever used
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, the
system
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 returned by
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 some type
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
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 things
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
used
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 and
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:
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:
|
| * Add
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 group.
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 which
[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 model (in
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 template
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 name and
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 use
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 the calling
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
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
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 Phillip. Time for
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.
How do
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, to
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)
29 matches
Mail list logo
