[Web-SIG] Standardized template API

[Ian Bicking]

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  |  ianb at colorstudy.com  |  http://blog.ianbicking.org