[Web-SIG] [server-side] request/response objects

[Greg Stein]

In the most recent incarnation of a webapp of mine (subwiki), I almost
went with a request/response object paradigm and even started a bit of
refactoring along those lines. However, I ended up throwing out that
dual-object concept.

When you stop and think about it: *every* request object will have a
matching response object. Why have two objects if they come in pairs? You
will never see one without the other, and they are intrinsically tied to
each other. So why separate them?

I set up the subwiki core to instantiate a "handler" each time a request
comes in. That Handler instance provides access to the request info, and
is the conduit for generating the response. The app dispatches to the
appropriate command function, passing the handler.

The Handler is actually set up as a base class, with two subclasses so
far: cgi, and cmdline. This lets me do some testing from the command line,
along with the standard cgi model of access. At some point, I'll implement
a mod_python subclass to do the request/response handling.

(as a side note, I'll also point out that Apache operates this way, too;
 everything is based around the request_rec structure; it holds all the
 input data, output headers, the input and output filter chains, etc)


In any kind of server-side framework design, I would give a big +1 to
keeping it simple with a single "handler" type of object rather than a
dual-object design.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/