[Web-SIG] Standardized template API
Phillip J. Eby
pje at telecommunity.com
Wed Feb 1 23:15:26 CET 2006
At 02:48 PM 2/1/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>>My criteria is that it would be easy to implement Phillip's proposal in
>>>terms of mine (and I could provide a sample implementation of that if it
>>>would help), but it doesn't seem so easy to do the opposite.
>>Actually, I believe you've got that backwards. Many things the WSGI
>>embedding proposal can do, yours can't do *at all*, no matter how much
>>programming you do. vars'n'strings isn't a substitute for WSGI, but it's
>>easy to piggyback other payloads *out* of WSGI using file_wrapper-like
>>APIs or dual-use objects with "__call__" methods.
>What exactly can't I do with a WSGI application (a specific
>implementation) that uses the non-WSGI plugin API?
The "template" doesn't get to control the status or headers if all it can
do is return is a string.
>>>For instance, there's no way for a Cheetah template to extend a WSGI
>>>application. It can extend other Cheetah templates, and even other
>>>Python classes, but not a WSGI app.
>>Provide extension APIs to allow finding other templates. Putting them in
>>this context also helps make it clear that such APIs aren't -- and
>>*can't* be -- universal, because the templates themselves aren't
>>heterogeneous. You can't give a Cheetah template a Kid subtemplate.
>My API always indicates the type of object you are looking for, though
>that may be too strict, as you don't *always* want to have a single
>type. Though if there is a defined exception when a resource can't be
>found, maybe that could be handled at a higher level than find_resource.
I don't see what this gains over having WSGI as a universal fallback
protocol in this context. You always get WSGI, and maybe it also speaks
something "native" to you.
>Here's a rough WSGI implementation of active pages using the resource spec:
You've just presented a *convention*, not a standard. There's a big
difference. Standardizing on WSGI gives a level playing field for all
paradigms. Standardizing on strings clips other frameworks' wings, as your
example clearly demonstrates, and forces them to reinvent wheels that we've
already spent plenty of sweat and tears inventing.
Why are you against this, anyway, btw? There are plenty of obvious
benefits to extending the existing standard, and I'm not the only person
who's pointed out that a string-oriented approach doesn't allow them to do
things they want to do. There's also been scarcely any argument that you
can't trivially wrap string-oriented templates as WSGI resources.
So the question then boils down to this: who should be inconvenienced and
what capabilities should be crippled, and by how much? Your position calls
for inconveniencing nobody, but crippling any frameworks or templates that
are more powerful or flexible than the ones you favor. Mine calls for a
mild inconvenience to any framework that doesn't doesn't currently support
embedded WSGI, but it cripples *nobody*, and encourages frameworks to *add*
entirely new capabilities while enabling new kinds of WSGI-based tools.
More information about the Web-SIG