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
Okay, so now it's clear to me that some of the crosstalk on my proposal was
due to terminology issues. I'd like to propose a revised terminology for
discussing the various attempts at a templating standard, specifically:
publisher - the part of a system that determines what template is to be
u
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
13 matches
Mail list logo
