[Web-SIG] Standardized template API

[Phillip J. Eby]

At 05:42 PM 2/1/2006 -0500, Clark C. Evans wrote:
>| The "template" doesn't get to control the status or headers if all it
>| can do is return is a string.
>
>WSGI the hammer!  Must we necessarly have a nail here?

Who's "we"?  Strings don't meet *my* use cases, or those of other template 
system and application developers who are not necessarily here to defend 
themselves against the promulgation of a standard that will exclude or 
marginalize them, or who have been here but haven't figured out yet how the 
exclusion will affect them, or what opportunities will be lost by going 
down this road.  (Or who have already given up and left, as it appears Jim 
may have done, though it's also likely he's just busy at the moment.)

Anyway, for the "we" that I'm a member of, yes, there is definitely a nail.


>I think what's missing in this discussion is that templates are often
>used to build but a small part of an result; a left toolbar, a menu,
>perhaps even a row in a table -- but no more.

Actually, I've explicitly covered this in my most recent messages, even 
giving an example of a templating system that already supports dual usage 
of "page" and "fragment" modes, where the page mode is more like WSGI and 
the fragment mode is more like strings for the *same* template, so it can 
be used as a page *or* in embedded form.


>   I think that the
>requirements and design constraints involved make them so different from
>full-fledged WSGI applications/filters that even thinking about them in
>WSGI terms isn't helpful.

Neither is it harmful.  I'm not proposing that subtemplates be required to 
use WSGI, simply because most templating systems don't offer much 
heterogeneity in what their subtemplates can consist of, especially for 
layouts ("macros" in ZPT terms, or "template inheritance" in many other 
systems' terms).

But, going the opposite way, to string-centrism, *will* be harmful.  Even 
the example of PHP or ASP should be sufficient to show that some templates 
*need* to have the option of controlling their response.  A standard that 
ignored this would clearly be broken.

I'm beginning to think that I'm going to have to come up with a better 
metaphor to explain what I'm seeing here.  Focusing on plugging string 
templates and aggregation is like trying to design a standard for USB-based 
power when we don't have *wall current yet*.  Sure, it's nice for powering 
all your little mice and keyboards and such, but you're never going to be 
able to plug a dishwasher into it.  You can always transform *down* from 
wall current to run a peripheral, or to power a USB hub, but if all you 
have is USB power, everybody who needs household appliances is out of luck.

Ergo, it makes more sense to standardize wall current (WSGI embedding) 
*first*, and then move down to more fine-grained concerns like powering USB 
hubs (sub-template linkage in homogeneous or heterogeneous template systems).

So far, the whole of the arguments presented *against* the WSGI embedding 
approach seem to be that I've proposed something that has *too much* 
ability.  What a lousy no-good person I am, proposing things that 
accomplish more and allow more templating systems to participate in the 
standard.  Shame on me!  ;)

Seriously, though, does anybody have any arguments against WSGI embedding 
*besides* it requiring a little extra wrapping in certain subtemplate 
scenarios?  Anything that stacks up against the huge list of benefits it 
offers?  Does anybody believe they have a way to support response control 
from templates without a kludged-on convention that's not part of the 
standard, and isn't just another WSGI in sheep's clothing?

C'mon guys, where's the shooting down of my ideas that y'all promised?  ;)