[Web-SIG] WebOb

[Ian Bicking]

Guido van Rossum wrote:
> 2007/10/22, Ian Bicking <ianb at colorstudy.com>:
>> I redid the front page to make it more brief: http://pythonpaste.org/webob/
> 
> Much better; I'll try to review it in more detail later. Right now a
> few details jump off the page to me: GET and POST are verbs and IMO
> poor names for what they represent; 

I generally agree, and initially they were named queryvars and postvars. 
  But I provided GET and POST aliases for compatibility with both Pylons 
and Django, and then I kind of decided that though they are technically 
incorrect (e.g., GET variables are really query string variables, and 
can be present in POST requests) that it wasn't worth the ambiguity of 
aliases, and I didn't want to just change the names.

> params is usually called query (isn't it?);

I'm not aware of any particular convention for this.  In Django it's 
request.REQUEST, in Werkzeug it is req.values, in Webware it was 
accessed with request.value(name), and I believe CherryPy uses 
request.params.  So there isn't any convention that I know of.

> and what's the advantage of using Request.blank() instead
> of simply Request()?

As Tres said, it creates a request from scratch, building the WSGI 
dictionary.  I use it for testing and potentially for artificial 
requests or subrequests (though subrequests usually work better with 
request.copy_get()).  When you are serving an application the WSGI 
environment will always come from the WSGI server.

>> I stopped with the example, because I couldn't think of a good example.
>>   Maybe a different evening.  Suggestions of course welcome.
>>
>>>> For realistic use cases, some kind of infrastructure is necessary.
>>> How realistic are we talking? I'm thinking of something that I can
>>> test by pointing my browser to localhost:8080 or similar. For CGI
>>> scripts, the standard library's CGIHTTPServer would suffice. How hard
>>> is it to create something similar for WSGI or for webob?
>> Well, some kind of WSGI adapter; the wsgiref one is fine.  The file
>> example I guess is boring, because without some kind of dispatch you can
>> only serve up one file.  A most boring server.
>>
>> Wiki is a common example, but a little too common at this point.  WebOb
>> doesn't offer anything for HTML either, so it would be a somewhat
>> unsatisfying example anyway I suspect.
> 
> The file-serving example has several shortcomings: the presentation
> order seems odd, some things are introduced without explanation of
> what or why. (Why is UTC imported? Why is mimetypes imported twice?
> Why bother with calculating the mime-type at all in the first
> example?) Towards the end it seems to go into too many details of
> serving up conditional responses and file ranges, which seem better
> suited for an advanced manual.
> 
> I suggest the wiki-in-one-page would be a better example, even if you
> consider it too common (serving static files isn't common? :-).

But I love static files!  I wonder if there's an interesting piece of 
middleware I could do -- WebOb makes middleware much easier IMHO.  Of 
course, it's only interesting if you have something on the other end of 
your middleware.

Maybe a backend app that serves files and knows GET and PUT, and then 
middleware that turns it into a wiki?  Or is that too clever? 
Authentication middleware with a login page?  Maybe too meta.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org