Although I've been trying to follow this thread, I'm finding it
difficult to get a handle on what is meant to *call* the template API
(e.g. what typically calls "render" in Ian's ITemplatePlugin
interface at http://svn.pythonpaste.org/home/ianb/templateapi/
interface.py)? Is the framework m
Chris McDonough wrote:
> Although I've been trying to follow this thread, I'm finding it
> difficult to get a handle on what is meant to *call* the template API
> (e.g. what typically calls "render" in Ian's ITemplatePlugin interface
> at http://svn.pythonpaste.org/home/ianb/templateapi/ inte
At 08:02 PM 2/5/2006 +, Alan Kennedy wrote:
>Looking at this in an MVC context, the application is responsible for
>populating the Model (user namespace), and selecting which View
>(template<->media-type) is suitable for return to the user. Templates
>should not vary media types. HTTP headers d
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 t
> Instead, I think the right approach is to continue with the existing
> approach: put the most basic possible WSGI server in the standard
> library, for educational purposes only, and a warning that it shouldn't
> really be used for production purposes.
I strongly disagree with this thinking.
>From your original spec:
def __init__(extra_vars_func=None, options=None):
"""
[Is ``extra_vars_func`` necessary? Couldn't it be handled by
a wrapper around ``render``?]
I think you're right. I don't see any need for extra_vars_func. I
think extra_vars_func was a side eff
On Feb 6, 2006, at 11:50 AM, Kevin Dangoor wrote:
> I'm not keen on the wsgi_environ and set_header_callback options,
> because I don't perceive a true need for *this* API to be tied to the
> web. Of course, you need these if the template itself is going to set
> any of the headers, but there is s
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 t
Bill Janssen wrote:
>>Instead, I think the right approach is to continue with the existing
>>approach: put the most basic possible WSGI server in the standard
>>library, for educational purposes only, and a warning that it shouldn't
>>really be used for production purposes.
>
>
> I strongly di
Kevin Dangoor wrote:
> On 2/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>> def render(template_instance, vars, wsgi_environ=None,
>> set_header_callback=None, **kwargs):
>
>
> I'm not keen on the wsgi_environ and set_header_callback options,
> because I don't perceive a t
Ian Bicking wrote:
> Anyway, I think general rules about this -- choosing simple
> or complete -- is only of limited utility. There are features
> that I think can and probably should be left out of the
> standard library. For instance, support for Keep-Alive and
> Continue. The server is 100%
Robert Brewer wrote:
> Ian Bicking wrote:
>
>>Anyway, I think general rules about this -- choosing simple
>>or complete -- is only of limited utility. There are features
>>that I think can and probably should be left out of the
>>standard library. For instance, support for Keep-Alive and
>>Cont
Robert Brewer said (in reference to CherryPy's WSGI server):
>> However, one thing CP's WSGI server currently does *not* have is the
>> ability for the user to configure SCRIPT_NAME. Christian Wyglendowski is
>> working on a patch for that at the moment
Ian Bicking said:
> I think this is a separa
I have no idea what any of these template specifications are about yet.
I do value your approach to being inclusive, and allowing as many as
possible styles to play.
As you have said yourself, I think many people can not understand what
everyone is talking about. So until people have something w
Christian Wyglendowski wrote:
> Robert Brewer said (in reference to CherryPy's WSGI server):
>
>>>However, one thing CP's WSGI server currently does *not* have is the
>>>ability for the user to configure SCRIPT_NAME. Christian Wyglendowski is
>>>working on a patch for that at the moment
>
>
> Ia
Michael Bayer wrote:
> 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 kno
Ian Bicking wrote:
> It doesn't really need to do that, it's easy to do that in the WSGI
> application itself. For instance:
>
> def dispatch(app_map):
> I can understand this is a common desire and it is not obvious that you
> can do this, so it might be useful to include some mid
On Feb 6, 2006, at 9:16 PM, Ian Bicking wrote:
>
> The inversion of control is the tricky part. In something like
> Cheetah, Kid, or ZPT the template (as represented solely by the
> file contents) gets control first, and then explicitly hands it off
> to whatever it is "inheriting" from (t
Title: [Web-SIG] Who is responsible for SCRIPT_NAME?
Ian Bicking said:
> The HTTP server should always set SCRIPT_NAME to ''.
Christian asked:
> If it is a full blown WSGI compliant HTTP server,
> why should it do that? Shouldn't it support mounting
> applications at various points (SCRIPT_N
19 matches
Mail list logo
