[Web-SIG] Standardized template API

[Michael Bayer]

is it possibly of value to just put some of these ideas into practice  
first without shooting any of them down ?  I find it very hard to  
come up with broad-ranging specs, and then declare it as "thats the  
way it will be", without having a decent community of folks trying  
out the ideas and seeing how far they fly, having a spec be more of a  
"living document" that can iteratively settle down to something known  
to be solid, rather than a hypothetical notion that becomes a rule  
without being put through real-world paces.   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?   Should those of us concerned about WSGI maybe try out a WSGI- 
centric idea and see how that goes ?  Even though I am skeptical of  
it, I've hardly any concept of what it would even look like.

The way it seems, there is a whole bunch of people playing with  
template languages and connecting them to view/controller frameworks,  
who want interoperability, and something has grown out of that which  
is definitely useful.  Then there is a whole host of other issues  
being laid out which to me at least, arent so tangible, that such a  
spec is too limiting and shuts out a lot of important use cases...can  
we get tangible examples down of this ?  can we get a clearer view,  
for those of us who cant necessarily work the entire problem space  
out in the hypothetical, of some real-world examples ?   Discussions  
like these, which go on and on without too many tangibles, I think  
can suffer due to an excessive amount of abstraction which shuts out  
a lot of potentially valuable participants...there needs to be more  
code and less hand-waving.

On Feb 1, 2006, at 6:52 PM, Phillip J. Eby wrote:

> 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 at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/mike_mp% 
> 40zzzcomputing.com