[Web-SIG] Standardized template API

[Daniel Miller]

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.
>