[Web-SIG] Standardized template API

[Ian Bicking]

Phillip J. Eby wrote:
> At 01:48 PM 2/2/2006 -0500, Michael Bayer wrote:
> 
>>Can those of us who
>>have worked less with "the high end" see some real examples of what
>>they need, and how they will be marginalized by a template adapter
>>API?
> 
> 
> Have you ever used PHP?  ASP?  DTML?  Specifically, have you ever used them 
> to generate any content-type other than HTML?  This is a trivial example of 
> a use case that a vars'n'strings approach doesn't support, without 
> basically reinventing a new protocol that duplicates WSGI.

Yes, I've used them, and they work pretty much like the example WSGI app
I gave.  There are functions -- callbacks from our perspective -- that
let you set the headers.  All the output is sent on to the browser, or
perhaps returned as a string.  Though usually there is no "return"
value, it is all sent to the browser -- for instance, if you wanted to
capture the output of a PHP template included from another template, I
believe you have to essentially redirect output, run the other PHP
script, then restore output and get the text that was captured.  There's
no particular support for capturing other information, like headers that
were set.  This sounds like a dumb design, you say?  Sure, but we can be 
dumb-design-compatible!

DTML allows capturing, but no special support for headers or metadata.
And I guess it has the concept of a return value, but I suppose I've
never understood or used that, since Python Scripts existed by the time
I started using DTML, and they handled those kinds of cases better.

I dunno, I just don't get it when it comes to template-as-WSGI-apps.
And if it's gettable, I kinda feel like I should get it.  So I'm not 
sure it's going to make sense to people.

I still feel quite comfortable with the API I posted earlier, though I'm 
sure some additions would be good.  It is close to the TG/Buffet API, 
but with a little inversion that I think allows (but does not specify) 
for intelligent resource resolution.

I'm all for decomposing things into WSGI when it is appropriate.  But I 
also think there's lots of complimentary APIs that aren't directly 
associated to WSGI.  My motto: small standards, loosely joined.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org