[Web-SIG] Standardized template API
ianb at colorstudy.com
Wed Feb 1 04:04:43 CET 2006
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
> 3. Doesn't allow the framework to control the lifetime of compiled
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
> 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
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
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 | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG