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 meant to call "render"?
Sorry for the remedial question ;-)
- C
On Feb 5, 2006, at 5:19 PM, Phillip J. Eby wrote:
> At 02:46 PM 2/5/2006 -0600, Ian Bicking wrote:
>> Ian Bicking wrote:
>>> def render(template_instance, vars, format="html",
>>> fragment=False):
>>
>> Here I can magically turn this into a WEB templating spec:
>>
>> def render(template_instance, vars, format="html", fragment=False,
>> wsgi_environ=None, set_header_callback=None)
>>
>> wsgi_environ is the environ dictionary if this is being called in
>> a WSGI
>> context. set_header_callback can be called like
>> set_header_callback(header_name, header_value) to write such a
>> header to
>> the response. Frameworks may or may not allow for setting
>> headers. If
>> they don't allow for it, they shouldn't provide that callback (thus
>> headers will not be mysteriously thrown away -- instead they will be
>> rejected immediately). [Should set_header_callback('Status', '404
>> Not
>> Found') be used, or a separate callback, or...?]
>>
>> This follows what all "server pages" templates I know of do. That
>> is,
>> they do not have special syntax related to any metadata (i.e.,
>> headers)
>> or even any special syntax related to web requests. Instead the web
>> request is represented through some set of variables available in the
>> template.
>
> Yes, but different template systems offer different APIs based on
> it; the
> idea of using WSGI here was to make it possible for them to offer
> their
> *own*, native APIs under this spec, not to force the use of the host
> framework's API.
>
> The only thing that's missing from your proposal is streaming
> control or
> large file support. I'll agree that it's an edge use case, but it
> seems to
> me just as easy to just offer a plain WSGI interface and not have to
> document a bunch of differences and limitations. OTOH, if this is
> what it
> takes to get consensus, so be it.
>
> The additional advantage to using plain ol' WSGI as the calling
> interface,
> however, is that it also lets you embed *anything* as a template,
> including
> whole applications if they provide a "template engine" whose syntax is
> actually the application's configuration.
>
> Anyway, the only differences I'm aware of between what you're
> proposing and
> what I'm proposing are:
>
> 1. Syntax sugar (each proposal sweetens different use cases)
> 2. Feature restrictions (yours takes away streaming)
> 3. What's optional (you consider WSGI optional, I want strings to
> be optional)
>
> It would be better, I think, to address further discussion to
> addressing
> the actual points of difference.
>
> Regarding #2, I'm willing to compromise to get consensus.
> Regarding #3,
> I'd be willing to compromise by making *both* optional, with clearly
> defined variations of the spec so that plugins and frameworks that
> support
> each are clearly distinguishable. This would also mean that we'd
> both be
> able to get the syntaxes we want under #1.
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%
> 40plope.com
>
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
