[Web-SIG] Standardized template API

[Phillip J. Eby]

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.