[Web-SIG] Standardized template API
Phillip J. Eby
pje at telecommunity.com
Thu Feb 2 00:52:24 CET 2006
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
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? ;)
More information about the Web-SIG