Standardized template API

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 template (so, for
instance, you can use relative 
>>>names to the template you inherit from).
>>
>>I don't want plugins to affect *where* templates are
retrieved from, or 
>>how their names are interpreted.  A template
engine's only job should be 
>>to turn a string or stream into a template object.
>>
>>What I was proposing we do was establish a common
mechanism for finding 
>>templates and other resources, taking into account
i18n, skinning, 
>>polymorphism, and eggs.  That would have a much
greater impact on the 
>>Python web world than simply formalizing the
Buffet/TurboGears plugin 
>>mechanism.
>
>find_template is provided *to* the plugin, *from* the
framework, so I 
>believe it fits what you describe.  Well, the
implementation of that 
>finding algorithm is not in the spec, but making a good
implementation can 
>be tackled separately; it will be more interesting when
we also have a 
>specific resource to find (templates).

What I'm getting at is that a standardized way for a
deployer to provide 
templates to "skin" or localize an application has
vastly wider 
applicability than the template plugin mechanism being
discussed, and is 
much more relevant to standardization.


>>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 application object, then it provides a maximum
of flexibility.  If 
>>individual frameworks want to supply additional data
or features, they 
>>can do so via additional environ keys.
>
>I feel comfortable with ultimately doing a
render(template, vars) call, 
>which is widely supported in quite a few templating
languages.  Turning it 
>into a WSGI app seems like a bigger stretch, and one
that I'm not sure is 
>necessary, and one I'm pretty sure will scare some
people off ;)

But the upsides are:

1. Less to specify
2. More flexibility
3. Fewer protocols for a framework developer to learn
4. Complete access to the request
5. Complete control over the response


>Separately from this, I have my own ideas as well about
a WSGI middleware 
>for skinning, but that's something else entirely.  What
we have here is 
>very much within the reach of immediately implementing
and using in 
>several frameworks.

And like Jim, I have little interest in it, as it doesn't
solve any of the 
interesting problems.

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.  It's a niche solution to a niche
problem, which is 
allowing web frameworks to offer an illusion of choice to
developers.

However, the existence of a "blessed" spec along
those lines would send a 
message that this is a solved problem, just use that spec
and everything is 
fine, when a whole area of solutions is completely closed
off.  I can just 
see people complaining about Zope not supporting the spec,
no matter that 
the spec doesn't come anywhere close to addressing the
problems Zope is 
solving.

The problem I'd like to see a template/resource spec solve
is this: give 
developers and deployers a way to package templates and
other static or 
dynamic resources for an application.  All frameworks can
benefit from 
this, especially if there need only be a single
implementation of the 
API.  Solving this problem *also* solves the problems solved
by the 
Turbo/Buffet plugin API as a side effect, because you have
to be able to 
specify somehow what code gets used to turn a resource
specification into 
something executable.


>>I don't know if it's politically or technically
feasible to actually 
>>solve this, since some template engines bundle a lot
of assumptions 
>>presently, like the idea that a template is a Python
module or stuff like 
>>that.  Some frameworks currently bundle assumptions
of their own about 
>>such things.  Getting to a workable standard might
require some compromises.
>
>While a standard is useful, you won't be able to drop
templates in 
>willy-nilly into applications and have them work.

That's not really the goal of what I'm proposing, and it's
also why I think 
focusing on the interface between the framework and
templating tool is way 
too narrow a niche.


>>On the positive side, relatively few frameworks
support the full range of 
>>i18n, skinning, polymorphism, and egg resource
options, and so fewer 
>>conflicts are likely the more you get into the high
end.  For example, 
>>Zope 3 supports skins and i18n, but not really eggs
and I'm not sure it 
>>does polymorphism.  peak.web currently does
polymorphism, skins, and 
>>eggs, but doesn't do much w/i18n as yet.  Creating a
standard would 
>>enhance the capabilities and deployability of *all*
participating 
>>frameworks, however, so it seems to me to be worth a
go.
>>The downside, on the other hands, is that since so
few frameworks try to 
>>solve the the high-end problems, there's likely to
be less widespread 
>>understanding of what the problems are or why you'd
want to solve them.
>>This is the flip side of the issue Jim Fulton
pointed out, which is that 
>>people who work at the high end of the problem scale
don't see much 
>>benefit in the Turbo/Buffet templating API, because
it bakes in way too 
>>many assumptions to allow you to solve any really
interesting problems with it.
>
>Then Jim and others should give more pushback about the
issues they see.

That's what I'm doing.  

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 
>>>> resolve template names relative to the
calling template (so, for 
>>>> instance, you can use relative names to the
template you inherit from).
>>>
>>>
>>> I don't want plugins to affect *where*
templates are retrieved from, 
>>> or how their names are interpreted.  A template
engine's only job 
>>> should be to turn a string or stream into a
template object.
>>>
>>> What I was proposing we do was establish a
common mechanism for 
>>> finding templates and other resources, taking
into account i18n, 
>>> skinning, polymorphism, and eggs.  That would
have a much greater 
>>> impact on the Python web world than simply
formalizing the 
>>> Buffet/TurboGears plugin mechanism.
>>
>>
>> find_template is provided *to* the plugin, *from*
the framework, so I 
>> believe it fits what you describe.  Well, the
implementation of that 
>> finding algorithm is not in the spec, but making a
good implementation 
>> can be tackled separately; it will be more
interesting when we also 
>> have a specific resource to find (templates).
> 
> 
> What I'm getting at is that a standardized way for a
deployer to provide 
> templates to "skin" or localize an
application has vastly wider 
> applicability than the template plugin mechanism being
discussed, and is 
> much more relevant to standardization.

I don't see why that needs to be related to this spec,
except to allow 
for it.  find_template/find_resource allows for arbitrarily
complex 
rules to identify resources (at least seem so to me), but
does not 
provide or specify any standard way to do this.

>>> 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 application object, then it
provides a maximum of 
>>> flexibility.  If individual frameworks want to
supply additional data 
>>> or features, they can do so via additional
environ keys.
>>
>>
>> I feel comfortable with ultimately doing a
render(template, vars) 
>> call, which is widely supported in quite a few
templating languages.  
>> Turning it into a WSGI app seems like a bigger
stretch, and one that 
>> I'm not sure is necessary, and one I'm pretty sure
will scare some 
>> people off ;)
> 
> 
> But the upsides are:
> 
> 1. Less to specify
> 2. More flexibility
> 3. Fewer protocols for a framework developer to learn
> 4. Complete access to the request
> 5. Complete control over the response

The spec we have has few or no bindings to HTTP, and is
usable (and 
useful) outside of HTTP.  You could build a single WSGI
implementation 
on top of this spec, and use the spec to make that WSGI
implementation 
support any template language that uses this spec.

>> Separately from this, I have my own ideas as well
about a WSGI 
>> middleware for skinning, but that's something else
entirely.  What we 
>> have here is very much within the reach of
immediately implementing 
>> and using in several frameworks.
> 
> 
> And like Jim, I have little interest in it, as it
doesn't solve any of 
> the interesting problems.
> 
> 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.  It's a niche solution to a
niche problem, which 
> is allowing web frameworks to offer an illusion of
choice to developers.

I don't buy that.  I think if frameworks expose not just the
result of 
render, but also the result of load_template, then this can
to some 
degree support all templating languages.  I think 
find_template/find_resource can support a wide variety of
techniques for 
finding resources, and if a compelling spec or
implementation of that 
function comes about, then that's great, but that doesn't
invalidate the 
spec, nor is it required to use the spec.

> However, the existence of a "blessed" spec
along those lines would send 
> a message that this is a solved problem, just use that
spec and 
> everything is fine, when a whole area of solutions is
completely closed 
> off.  I can just see people complaining about Zope not
supporting the 
> spec, no matter that the spec doesn't come anywhere
close to addressing 
> the problems Zope is solving.

OK, then you'll have to go into more depth why the API
provided is 
wrong.  Not why it isn't enough -- it's not the end-all and
be-all of 
templating or anything -- but why what it *does* provide is
not 
sufficient or correct.

> The problem I'd like to see a template/resource spec
solve is this: give 
> developers and deployers a way to package templates and
other static or 
> dynamic resources for an application.  All frameworks
can benefit from 
> this, especially if there need only be a single
implementation of the 
> API.  Solving this problem *also* solves the problems
solved by the 
> Turbo/Buffet plugin API as a side effect, because you
have to be able to 
> specify somehow what code gets used to turn a resource
specification 
> into something executable.

That's a separate issue.  If you -- or someone else at some
future time 
-- can provide an implementation of
find_template/find_resource that 
does these things, then I think you'll have what you want.

>>> I don't know if it's politically or technically
feasible to actually 
>>> solve this, since some template engines bundle
a lot of assumptions 
>>> presently, like the idea that a template is a
Python module or stuff 
>>> like that.  Some frameworks currently bundle
assumptions of their own 
>>> about such things.  Getting to a workable
standard might require some 
>>> compromises.
>>
>>
>> While a standard is useful, you won't be able to
drop templates in 
>> willy-nilly into applications and have them work.
> 
> 
> That's not really the goal of what I'm proposing, and
it's also why I 
> think focusing on the interface between the framework
and templating 
> tool is way too narrow a niche.

I, and several other people who have already started
usefully using this 
spec as is, don't feel that way.  We feel it's useful enough
right now, 
even with notable problems around its current (as described
on the TG 
page) module-oriented perspective.

Please, say what is wrong about the spec itself, not what is
wrong about 
the scope of the spec.

-- 
Ian Bicking  |  ianbcolorstudy.com  |  http://blog.ianbicking.org

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 common denominator

2. It doesn't give templates access to the request or
response without 
creating new specifications for how they're to be encoded in
vars -- which 
would end up recapitulating the pre-WSGI "common
request/response" 
arguments all over again

3. Doesn't allow the framework to control the lifetime of
compiled resources

4. Lack of relationship to HTTP makes it
irrelevant/out-of-scope for 
Web-SIG; it should go to a string or text processing SIG.

5. Makes Web-SIG do-over a problem that TurboGears and
Buffet have already 
solved.  (That is, there's already a usable solution for
what this does; it 
doesn't need *another* specification; let's use the current
focus of 
attention to go after an actual opportunity to *improve*.)

Problems 1-4 are simple to solve by having resources be WSGI
application 
objects.  The rest of the standardization could then be
reduced to what 
additional environ keys should be supplied by frameworks. 
And then we 
could get to work on solving the resource deployment problem
instead.

Look-and-feel customizability of reusable web application
components is an 
incredibly important problem, on a scale comparable to the
problems that 
setuptools and eggs solve, and it's a much bigger issue for 
man-in-the-street use of Python as a web platform than WSGI
itself is.  My 
wife isn't a programmer, but she's hacked PHP applications
to customize 
their look and feel.  (Of course, these apps then aren't
really upgradeable 
any more, because their code has effectively been branched.)

A Python standard for resource location would allow us to
have tools that 
run against a project and spit out a directory tree with
just resources for 
you to edit, and to build eggs of your newly-customized UIs.
 If this is a 
*standard* for Python web apps, then it means you only learn
it 
once.  Sure, you'll have to learn the template syntax used
by different 
apps or components, but that's not a big deal if you're
mainly looking to 
change the HTML anyway.  Also, it enables a market for
third-party 
customizations: i.e., people creating skins for popular
components/apps.

If we can solve the resource deployment problem in a way
that allows 
creating tools that people like my wife can use, we will
have succeeded in 
moving the Python web platform forward significantly, in
terms of what will 
be available to users, not just developers.


_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 templates) 
> by reducing everything to the least common denominator

I think exposing load_template is an escape for template
languages that 
don't fit into the standard dictionary-in-string-out
approach.  Besides 
that, I don't know what Better Solution we're talking about.

> 2. It doesn't give templates access to the request or
response without 
> creating new specifications for how they're to be
encoded in vars -- 
> which would end up recapitulating the pre-WSGI
"common request/response" 
> arguments all over again

The spec doesn't say anything about the variables passed in.
 I guess 
there's an implication that it is a dictionary, though that
might not be 
necessary.  The request and response are variables.  Why
would they be 
something other than variables?  Even in Zope they are
variables, right?

The actual templates written are implicitly bound to the
application and 
the framework, and the application is bound to the template
language, 
and maybe we can solve that problem later.  This just
handles the 
template/framework binding.

> 3. Doesn't allow the framework to control the lifetime
of compiled 
> resources

Ok... so what should we do?  We can say that .load_template
is not 
allowed to cache the thing it returns, and require
find_resource to do 
the caching.

> 4. Lack of relationship to HTTP makes it
irrelevant/out-of-scope for 
> Web-SIG; it should go to a string or text processing
SIG.

There isn't such a sig.  And it's all just mailing lists
anyway.  The 
people who care about this now are doing web work.

> 5. Makes Web-SIG do-over a problem that TurboGears and
Buffet have 
> already solved.  (That is, there's already a usable
solution for what 
> this does; it doesn't need *another* specification;
let's use the 
> current focus of attention to go after an actual
opportunity to *improve*.)

We have discussed some improvements on the TG list, and I've
tried to 
bring those up here as well.  And the interface is like a
couple weeks 
old, so it's not like this particular solution is As Old As
The Hills 
and shouldn't be considered by a wider audience before
moving forward.

> Problems 1-4 are simple to solve by having resources be
WSGI application 
> objects.  The rest of the standardization could then be
reduced to what 
> additional environ keys should be supplied by
frameworks.  And then we 
> could get to work on solving the resource deployment
problem instead.
> 
> Look-and-feel customizability of reusable web
application components is 
> an incredibly important problem, on a scale comparable
to the problems 
> that setuptools and eggs solve, and it's a much bigger
issue for 
> man-in-the-street use of Python as a web platform than
WSGI itself is.  
> My wife isn't a programmer, but she's hacked PHP
applications to 
> customize their look and feel.  (Of course, these apps
then aren't 
> really upgradeable any more, because their code has
effectively been 
> branched.)

These are all important issues -- I entirely agree.  When I
wrote a list 
of features I'd want in an ideal web development environment

(http://blog.ianbicking.org/ideal-webdev-environment.html
), these kind 
of features take up a sizable portion of the list.  But I
don't see how 
this spec -- or particularly the spec I proposed in response
to you 
(http://mail.python.org/pipermail/web-sig/2006-
February/001926.html) -- 
disallows these kinds of features being developed in the
future.  In 
fact quite the contrary!  By giving that resource finding
process a name 
and purpose -- even if not an implementation -- I think this
spec 
strongly encourages such development (or extraction) in the
future.  I 
just can't see why one needs to be a prerequesite for the
other.  But 
people want the template plugin *now*, and working on what
people want 
is generally a good strategy.

-- 
Ian Bicking  |  ianbcolorstudy.com  |  http://blog.ianbicking.org

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 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 common denominator
> 
> 2. It doesn't give templates access to the request or
response without 
> creating new specifications for how they're to be
encoded in vars -- which 
> would end up recapitulating the pre-WSGI "common
request/response" 
> arguments all over again
> 
> 3. Doesn't allow the framework to control the lifetime
of compiled resources
> 
> 4. Lack of relationship to HTTP makes it
irrelevant/out-of-scope for 
> Web-SIG; it should go to a string or text processing
SIG.
> 
> 5. Makes Web-SIG do-over a problem that TurboGears and
Buffet have already 
> solved.  (That is, there's already a usable solution
for what this does; it 
> doesn't need *another* specification; let's use the
current focus of 
> attention to go after an actual opportunity to
*improve*.)
> 
> Problems 1-4 are simple to solve by having resources be
WSGI application 
> objects.  The rest of the standardization could then be
reduced to what 
> additional environ keys should be supplied by
frameworks.  And then we 
> could get to work on solving the resource deployment
problem instead.
> 
> Look-and-feel customizability of reusable web
application components is an 
> incredibly important problem, on a scale comparable to
the problems that 
> setuptools and eggs solve, and it's a much bigger issue
for 
> man-in-the-street use of Python as a web platform than
WSGI itself is.  My 
> wife isn't a programmer, but she's hacked PHP
applications to customize 
> their look and feel.  (Of course, these apps then
aren't really upgradeable 
> any more, because their code has effectively been
branched.)
> 
> A Python standard for resource location would allow us
to have tools that 
> run against a project and spit out a directory tree
with just resources for 
> you to edit, and to build eggs of your newly-customized
UIs.  If this is a 
> *standard* for Python web apps, then it means you only
learn it 
> once.  Sure, you'll have to learn the template syntax
used by different 
> apps or components, but that's not a big deal if you're
mainly looking to 
> change the HTML anyway.  Also, it enables a market for
third-party 
> customizations: i.e., people creating skins for popular
components/apps.
> 
> If we can solve the resource deployment problem in a
way that allows 
> creating tools that people like my wife can use, we
will have succeeded in 
> moving the Python web platform forward significantly,
in terms of what will 
> be available to users, not just developers.
> 
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

On 1/31/06, Phillip J. Eby <pjetelecommunity.com>
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.  It's a niche solution to a niche
problem, which is
> allowing web frameworks to offer an illusion of choice
to developers.

There may need to be two discussions here. There are some
minor tweaks
to the current TurboGears template plugin spec that people
want. I
don't know how many people are using those plugins, but I do
know that
there are at least three. I'm fine with taking a first step
of making
our changes to the simple variable-to-string interface and
having that
be a de facto standard among those of us using these
plugins.

If we can devise a standard that builds on WSGI in some
useful way and
allows for more uses and wider adoption, as Phillip
suggests, that
does seem like a fine goal for the web-sig. That effort is
not going
to stop or hinder those of us who are already using these
template
engine plugins happily, so I don't think we need to look at
this as an
either-or proposition. The PEP would only cover the larger
standard,
but we can still make good use of the tools we have today.

Kevin
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

Kevin Dangoor wrote:
> On 1/31/06, Phillip J. Eby <pjetelecommunity.com> 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.  It's a niche solution to a
niche problem, which is
>> allowing web frameworks to offer an illusion of
choice to developers.
> 
> There may need to be two discussions here. There are
some minor tweaks
> to the current TurboGears template plugin spec that
people want. I
> don't know how many people are using those plugins, but
I do know that
> there are at least three. I'm fine with taking a first
step of making
> our changes to the simple variable-to-string interface
and having that
> be a de facto standard among those of us using these
plugins.

I am fine with that.  While the current vars-to-strings
template plugins 
might not solve any "interesting" problems, they
can (and do) make life 
easier for folks writing web apps in frameworks that use
them.

> If we can devise a standard that builds on WSGI in some
useful way and
> allows for more uses and wider adoption, as Phillip
suggests, that
> does seem like a fine goal for the web-sig. That effort
is not going
> to stop or hinder those of us who are already using
these template
> engine plugins happily, so I don't think we need to
look at this as an
> either-or proposition. The PEP would only cover the
larger standard,
> but we can still make good use of the tools we have
today.

Right.

Christian
http://www.dowski.com

ps - my first post to the WEB-SIG 

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 application object, then it provides a
maximum of 
| >>flexibility.  If individual frameworks want to
supply additional data 
| >>or features, they can do so via additional environ
keys.

Let's follow this idea through.  Would the ``environ``
essentially act
like the dict that most template engines already use for
input?  Or
would it require something like environ['wsgi.result'] be a
dict that
acts as this primary input?  How does this application get
its input?

As I've been converting my application to WSGI, I've put my
"templating"
stuff as a *response* filter.  It gets JSON input (as a
string) from 
the output stream of the previous stage...  yea, I encode
and then
decode so it isn't fast.  But it works and is very general. 

Perhaps the WSGI application specification should be
modified to allow
the response to be an interation over any sort of object
that can be
converted to a str?  This would allow filters to be written
w/o emitting
and re-parsing content in an intermediate format.

| >I feel comfortable with ultimately doing a
render(template, vars) call, 
| >which is widely supported in quite a few templating
languages.  Turning 
| >it into a WSGI app seems like a bigger stretch, and
one that I'm not 
| >sure is necessary, and one I'm pretty sure will scare
some people off ;)
| 
| But the upsides are:
| 
| 1. Less to specify
| 2. More flexibility
| 3. Fewer protocols for a framework developer to learn
| 4. Complete access to the request
| 5. Complete control over the response

I can see reasons why you'd want this.  A templating engine
could want
to use the ``HTTP_ACCEPT`` environment variable to determine
what sort
content to return (or raise an error, 404 if it doesn't
support any of
the content type suggested).  Similarly, I can see reasons
why a
templating engine might want to set specific response
headers.

...

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 escape for template
languages that 
| don't fit into the standard dictionary-in-string-out
approach.  Besides 
| that, I don't know what Better Solution we're talking
about.

I don't see how something like this disadvantages better
solutions. If
anything, I can see how it would enable quicker adoption of
better
solutions: an adapter from this "simple" interface
to the "better"
interface would be easy to construct and thus give out of
the gate
any better interface a leg-up.

| >2. It doesn't give templates access to the request or
response without 
| >creating new specifications for how they're to be
encoded in vars -- 
| >which would end up recapitulating the pre-WSGI
"common 
| >request/response" arguments all over again
| 
| The spec doesn't say anything about the variables passed
in.  I guess 
| there's an implication that it is a dictionary, though
that might not be 
| necessary.  The request and response are variables.  Why
would they be 
| something other than variables?  Even in Zope they are
variables, right?

Ian, my "templates" use the Accept header to
figure out what sort of
content variant to return; plus a quick peek at the
User-Agent for 
last-minute compatibility tweaks.  How does the
current/proposed
templating system support this?  These things arn't exactly
"inputs"
that get renderd into the output string.

| >3. Doesn't allow the framework to control the lifetime
of compiled 
| >resources
| 
| Ok... so what should we do?  We can say that
.load_template is not 
| allowed to cache the thing it returns, and require
find_resource to do 
| the caching.

Phillip, I fail to see how this is a problem.  Doesn't
Python have
garbage collecting and weak references? 

Best,

Clark
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 a template engine is
>| >>just a WSGI application object, then it
provides a maximum of
>| >>flexibility.  If individual frameworks want to
supply additional data
>| >>or features, they can do so via additional
environ keys.
>
>Let's follow this idea through.  Would the ``environ``
essentially act
>like the dict that most template engines already use for
input?  Or
>would it require something like environ['wsgi.result']
be a dict that
>acts as this primary input?  How does this application
get its input?

As I mentioned in my counter-proposal, there should probably
be a key like 
'wti.source' to contain either the object to be published
(for 
publisher-oriented frameworks) or a dictionary of variables
(for 
controller-oriented frameworks).  I originally called it
"published 
object", but that's biased towards publisher frameworks
so perhaps a more 
neutral name like 'source' or 'data' would be more
appropriate.

Ideally, I'd like for us to move forward with hammering out
the details of 
this and any other APIs that should be present in a WSGI
Template or WSGI 
Resource interface.


>Perhaps the WSGI application specification should be
modified to allow
>the response to be an interation over any sort of object
that can be
>converted to a str?  This would allow filters to be
written w/o emitting
>and re-parsing content in an intermediate format.

Actually, my 'wti.return_string' idea in a previous post
does this in a 
slightly different way.  Having return_foo APIs allows you
to return other 
types of objects that can be converted to normal WSGI or
left alone, 
according to whether the caller understands them.  Think of
it as a Python 
form of HTTP_ACCEPT.  

For an existing example of this idea, consider WSGI's
file_wrapper feature, 
that wraps a file as an iterable, but can bypass it and use
the file 
directly if no intervening middleware uses the iterable. 
This idea could 
be extended to DOMs or other kinds of objects.


>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 escape for
template languages that
>| don't fit into the standard dictionary-in-string-out
approach.  Besides
>| that, I don't know what Better Solution we're talking
about.
>
>I don't see how something like this disadvantages better
solutions. If
>anything, I can see how it would enable quicker adoption
of better
>solutions: an adapter from this "simple"
interface to the "better"
>interface would be easy to construct and thus give out
of the gate
>any better interface a leg-up.

No, it wouldn't.  The WSGI templating proposal effectively
requires the 
framework to allow resources full control of a WSGI
response, whereas a 
framework that just strips off the WSGI bits and only keeps
a string 
completely disempowers the template.  That's what I mean by
disadvantaging 
better solutions.

We can and should turn that around: disadvantage the
frameworks that 
*don't* let the resource have control, instead of
disadvantaging the 
resources that want to get control.

In fact, "template" is probably the wrong word for
us to be using here; the 
issue is more about embedding rich dynamic resources, only
some of which 
happen to be simple templates.  If we get that, we get
templates as a side 
effect.  But if we only do templates, we make it harder for
resource 
embedding to get a foothold.

(This reminds me a bit of the complaints when the Microsoft
CLR came out, 
that it basically makes every language into syntax sugar for
C#, while 
disadvantaging more dynamic languages by making them
relatively harder to 
implement and/or slower.  Only in this case, we're not
talking about 
something that can be worked around with partial
interpretation and fancier 
compiler techniques.)


>| >3. Doesn't allow the framework to control the
lifetime of compiled
>| >resources
>|
>| Ok... so what should we do?  We can say that
.load_template is not
>| allowed to cache the thing it returns, and require
find_resource to do
>| the caching.
>
>Phillip, I fail to see how this is a problem.  Doesn't
Python have
>garbage collecting and weak references?

The earlier proposal, if I understood it correctly, never
exposed a 
compiled template object to the framework, so GC and weak
references 
wouldn't have helped.  Any caching would've had to be done
by the engine 
without any input from the framework as to how long
something was needed.

Arranging the API to expose compiled resource objects would
fix that, since 
the framework could hold on to them as long as it liked, and
normal 
refcounting would take care of resource management.  And if
the engine 
wants to cache also, it can use a weak reference.

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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 thread pool behind a Twisted server, and
the thing  
doing the rendering is in "the main thread",
methods hanging off of  
the "published object" might try to make use of
thread-local storage,  
which would fail.  Zope 3 uses thread-local storage for
request  
objects, IIRC.

This might be a nonissue, because I'm a little fuzzy on
which  
component(s) actually do(es) the rendering of the template
in the  
models being proposed.  But the amount of fuzziness I have
about  
what's trying to be specified here makes me wonder if there
aren't  
better things to go specify.

>
> As I mentioned in my counter-proposal, there should
probably be a  
> key like
> 'wti.source' to contain either the object to be
published (for
> publisher-oriented frameworks) or a dictionary of
variables (for
> controller-oriented frameworks).  I originally called
it "published
> object", but that's biased towards publisher
frameworks so perhaps  
> a more
> neutral name like 'source' or 'data' would be more
appropriate.
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com