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