[Web-SIG] Standalone WSGI form framework.
ianb at colorstudy.com
Thu Mar 16 21:21:57 CET 2006
Alan Kennedy wrote:
>>I think "the one true web framework" could be made for Python if
>>someone took the best ideas from Spring WebMVC and made a few
>>component-ized building blocks on top of which complex and widely
>>varied applications could be built.
> Completely agreed. The term "meta-framework" is most appropriate, I
> think. If we could agree on a set of interfaces, then everyone would
> be free to contribute implementations of their own componments.
> For example, I like the idea of Routes URL-mapping library: it's
> precisely the kind of task that is simple enough in concept, but yet
> complex enough to require a dedicated (and thoroughly tested) library.
> Most of the popular web frameworks make the fundamental mistake of
> picking a single URL->object mapping mechanism, and making you
> shoehorn all your requirements into it. IIRC, Django, Turbogears,
> Pylons, all make this mistake.
> However, if URL->object mapping were controlled by an interface, then
> we'd be free to choose from multiple implementations, e.g.
> routes-style, quixote-style, zope-style, etc, etc.
I think WSGI can provide that, through successive rewriting of the
environment and dispatching to WSGI applications.
So Routes matches against PATH_INFO, and generally consumes everything
(though you can make it not consume everything -- but the use cases for
that are more limited since Routes is doing whole-path matching). Or in
RhubarbTart you traverse through objects, and if you reach a WSGI
application it adjusts SCRIPT_NAME and PATH_INFO, so the WSGI
application doesn't need to know the algorithm that determined it was
selected. And for systems that consume partial URLs, they don't need to
know what might consume the rest of the URL. So if you put a
Routes-based app in a RhubarbTart project, RhubarbTart only needs to
know that it has found a WSGI application.
>>However, to make this possible we'd most likely need a standard
>>request object (or at least an interface definition).
> ISTM that WSGI eliminates the need for that. Is there any specific
> thing you have in mind that WSGI doesn't cover?
We've recently kind of extracted the request object from RhubarbTart and
put it into Paste:
http://svn.pythonpaste.org/Paste/trunk/paste/request.py (Request class).
I generally have been wary of a common request object, but I like
this one, mostly because it is just a wrapper around the WSGI request
environment. So, while it can provide a common base (e.g., for
subclassing, or just using directly), the WSGI environment remains the
canonical location for information. So you could have ten different
eclectic instances of request objects running off the same single WSGI
request, and they should all work together.
Probably the biggest challenge I've seen in the past of a common(ish)
request object is that of scope. People include lots of different
things in request objects -- like the response, or the traversal
algorithm. But if you restrict it to what is in the WSGI environment,
the choices you have to make are much more constrained.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG