On Apr 15, 2005, at 5:30 PM, Paul Boddie wrote:
On Friday 15 April 2005 22:31, Blake Winton wrote:I'd love to find out that I'm wrong, although I guess I would find the WSGI idioms around accessing request headers/form-encoded data and collecting response information a bit cumbersome compared to the APIs provided by Webstack, Quixote, Webware, CherryPy, etc.
Is there any commonality between those APIs?
Perhaps. WebStack originally took some inspiration from Webware and the Java
Servlet API, but I think that the "vocabulary" is pretty standard, so it
isn't necessarily that difficult to map WebStack API methods to framework
methods. Quixote and CherryPy may have similar abstractions, but unlike most
of the frameworks supported by WebStack, these frameworks impose various
constraints (object publishing and template-orientation) that seemingly make
it impractical to support them in an API at WebStack's level.
Right - and that's fine. I'd rather see the frameworks follow a common set of "interfaces" for request/response/session/cookie/form objects then to have Webstack wrap the existing frameworks anyway.
Object publishing, template orientation, form toolkits, template systems, etc. is where I see each framework distinguishing itself from the next. The basic set of objects that wrap the HTTP lifecycle are very similar and I don't think anyone is choosing a framework based on these components.
You could split most Python based web frameworks into a couple layers I guess:
1. Gateway Interface and Middleware (WSGI)
2. HTTP Lifecycle Objects and APIs
3. Routing, Object Publishing, Servlet Mapping,
Validation, Form Handling, etc.
4. TemplatingLayer #2 seems like another obvious place, like WSGI, where compatibility could be beneficial and not overly stifling to the individual framework. I think layer #3 is where things start getting really messy because the techniques vary from framework to framework.
I realize I'm simplifying a bit - some pieces of functionality, like session management, blur between multiple layers and might be challenging to do well with additional restriction.
Ryan
_______________________________________________ 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
