[Web-SIG] Standalone WSGI form framework.

[Ian Bicking]

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