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? ;) _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com