Ticket #151 (new enhancement)
Proposal to enable non-delayed delivery of intermediate content while debug == true
| Reported by: | cemerick | Owned by: | ianb |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | paste | Version: | svn-trunk |
| Severity: | normal | Keywords: | intermediate content response generator debug spammed |
| Cc: | ben@… |
Description
As detailed in the pylons-discuss threads referenced below, paste/pylons collects all content yielded by an action (or a generator function explicitly attached to a Response) when debug == true. This is unfortunate, as it makes developing and debugging actions that do need to incrementally generate response content significantly more difficult than "normal" actions.
The core problem, as explained by Ben Bangert, is that the debug middleware needs to capture all of an action's response content before delivering it, so that it can display the interactive debugger if an error occurs.
My proposal is to allow actions to generate intermediate content without the debug middleware from delaying the delivery of output, but only when (a) an appropriate environment- or application-wide option is set in the effective .ini file, or (b) the action explicitly sets an appropriate attribute on the returned Response indicating that generator-yielded content should be delivered without delay. Neither of these approaches would impact existing applications until a developer chooses to utilize the option available described by approach (a), or sets the attribute mentioned in approach (b). Either way, if an error does occur after some content has been delivered to the client, thereby making the direct display of the interactive debugger impossible, a developer could easily pick the debug URL out of his or her console, and access backtrace information. If an error occurs before any content is delivered, then the debug middleware would be able to respond with the interactive debugger directly.
Personally, I believe that (b) is the superior approach -- it allows for each Response's behaviour within the debug middleware to be configured on an as-needed basis, is more local to the change at hand (i.e. doesn't introduce another .ini property) and probably represents less work overall.
http://groups.google.com/group/pylons-discuss/browse_frm/thread/32f4a69cfc4a170f http://groups.google.com/group/pylons-discuss/browse_frm/thread/2db53b1a91fa6f0a
