Decide what the first step of making twisted.web easier to use in unit tests is.
|Reported by:||radix||Owned by:|
HERE ARE SOME IDEAS: The solution to this ticket should be another ticket.
The ideal situation will allow us to instantiate a Request with no arguments, mash it together with a Site (or Resource?) to do the traversal and rendering, and get an introspectable Response object that allows us to assert things about the result of rendering the resource.
Result of conversation with Jean-Paul on 2007-01-07
Some of this plan doesn't take into consideration backwards compatibility, which of course must be maintained. To be revised.
- Request no longer needs any arguments, and does not directly interact with the channel or transport.
- In order to avoid calls to self.factory.log and self.channel.requestDone, the channel will call req.requestReceived and attach a callback to the deferred it returns (with maybeDeferred; some people may be overriding requestReceived) that logs the request and does other cleanup.
- Request.getResponse(site) -> (Deferred of) Response object does most of what Request.process does now, minus interactions with channel.
ACTUALLY MAYBE the request "processing" stuff should not be on the Request. PERHAPS the Request should be inerted, and instead be passed to a method somewhere else that sets everything up, does resource traversal and rendering, and returns a Response object.
ALSO think about request.write: it will need to put data into a BackwardsCompatibilityResponse or something.