At 09:58 PM 7/7/2008 +0200, Manlio Perillo wrote:
In this case the first solution is to use this middleware as a
decorator, instead of a full middleware.
This is the correct way to implement non-transparent middleware;
i.e., so-called middleware which is in fact an application API. See:
http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html
for more about this.
Basically, if a piece of middleware has to be there for the
application to run, it's not really "middleware"; it's a misnamed decorator.
In the original WSGI spec, I overestimated the usefulness of adding
extension APIs to the environ... or more likely, I went along with
some of Ian's overenthusiasm for the idea. ;-) Extension APIs in
the environ just mean you have to write your code to handle the case
where the API isn't there -- in which case you might as well have
used a library.
Extension APIs really only make sense if they are true *server*
features, not application features; otherwise, you are better off
using a library rather than "middleware" per se.
Under WSGI 2.0, it's even easier since you don't need decorators to
manipulate your response: you can just "return someapi(...)" where
the "..." is whatever you were going to return directly.
_______________________________________________
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
