[Web-SIG] Standardized template API
Phillip J. Eby
pje at telecommunity.com
Wed Feb 1 03:46:22 CET 2006
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.
More information about the Web-SIG