[Web-SIG] Request and Response objects

[Michael C. Neel]

> 1. This is a pretty good example of the fact that dual 
> objects don't do
> much other than introduce extra typing.

I think there is a lot of gain in dual objects, but I don't think anyone
is seeing the full idea yet - to blinded by low level details and how
it's always been done.

> 2. This is too low level of an example:

Argee.  I'd want to see something more like the following:

# if we have a ?type=pdf argument, send the response as a pdf
# otherwise just send the html

def handler(request, response):

	if request.args.get('type') == 'pdf':
		response.body = html_to_pdf(request.filename)
		response.headers["Content-type"] = 'appliaction/pdf'
	else:
		response.body = open(request.filename).read()

Notice I didn't do anythin about sending.  IMHO I should have to, the
"server" has the request object and the response object, it should be
able to send everything on it's own.  If I need to send for some odd
reason, I can overide that method for the server (borrowing again the
apache concept of phases to handle a request).

Now the html_to_pdf is a function I would have to develop, but it would
be nice if there was a response object that did this already.  So that
might looks something like:

def handler(request, response):

	if request.args.get('type') == 'pdf':
		response = PDFResponse(response)
		response.convert(request.filename)
	else:
		response.body = open(request.filename).read()	

The cool part is this html-to-pdf response object will work in medusa,
mod_python, cgi, etc (after everyone conforms to the standard of course
=D ).  Here I changed response objects mid stream, but I also see an
option where I tell the server which classes to use by default.

# This time I have a XML data store I want to put online
# I have written and XLST that will be applied to convert the data to
html
# The response class XLSTResponse does the needed dirty work for me

class MyHTTPServer(HTTPServer):

	# init is called only once per server instance
	def init(request, response):
		response.load_xlst('my_style_sheet.xlst')

	# handler is the content handler, called once per request
	def handler(request, response):
		response.parse(request.filename)


server = MyHTTPServer(response_class=XLSTResponse)
server.run()

Server configuration will of cource differ from server to server,
mod_python would probably take the class change though an httpd.conf
directive.  But the parts I like here are again that I can take the
response class to any server and also developers can focus only on the
side of the coin they are concerned with.  All I have to do to make a
legit response class is have my class be able to return a complete RFC
complient HTTP response - I am free from having to worry about
connection details and parsing the request.  this will make it much
eaiser I think to take existing code, say the ezt template system, and
wrap it to make it an HTTP response.  It would also be pretty easy to
replace the request object with one that does, say webdav for an
example.

I think if we explore this, other gains will be realised.  Someone
already mentioned pickling the different objects for debuging.  We could
have a method in the server called error_handler you could override that
was called whenever another handler raised an error and place the pickle
code there. (btw I think errors should be raised, not returned - it's
more python like that way, and less typing).

This could also solve some other issues on the list, such as how do you
want your form data parsed - just use the request class that parses the
data in a way you like.  That may not be 100% feasible though, since
there should be a standard way of passing a response object the
requests's parsed data, if it's needed.

Mike