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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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