[Web-SIG] Re: Just lost another one to Rails
Ryan Tomayko
rtomayko at gmail.com
Sat Apr 16 01:14:09 CEST 2005
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. Templating
Layer #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
More information about the Web-SIG
mailing list