Labels
Zend Framework: Zend_Controller_Request Output Buffering Component Proposal
| Proposed Component Name | Zend_Controller_Request Output Buffering |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Controller_Request Output Buffering |
| Proposers | Matthew Weier O'Phinney |
| Revision | 1.0 - 3 March 2007: Initial proposal (wiki revision: 3) |
Table of Contents
1. Overview
Zend_Controller_Response should be aggregate all responses emitted by the controller chain. This has the benefit of ensuring that headers are always emitted prior to content, as well as allowing the developer to write unit tests against their front controller. A simple way to do so would be to use output buffering.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- Output buffering will happen at the dispatcher level, surrounding the call to an action method
- Content captured by output buffering will be appended to the body content of the response object
- Developers will be able to turn off the output buffering feature via a front controller parameter
4. Dependencies on Other Framework Components
- Zend_Controller_Response_Abstract
- Zend_Controller_Dispatcher_Standard
- Zend_Controller_Front
5. Theory of Operation
This feature will be on by default and transparent to the end-user.
6. Milestones / Tasks
- Milestone 1: proposal
- Milestone 2: working code committed to the repo and tested
- Milestone 3: documentation of the feature
7. Class Index
- Zend_Controller_Dispatcher_Standard
8. Use Cases
| UC-01 |
|---|
| UC-02 |
|---|
9. Class Skeletons
I can't see a downside and is a pretty low impact change for those who don't want to use it.
We're going to need a master list of all the parameters that the "C" does something with soon though, as I'm losing track of the options available!
Regards,
Rob...
The ability to capture the "echo'd" output of all executed actions would be much more interesting to me, if the output was saved to a named body "segment" in the response object.
Explains the idea of named segments for response objects:
http://framework.zend.com/issues/browse/ZF-1024
Why? All of my code uses views and explicitly renders into "segments". Anything "echo'd" is a mistake that I would like to have logged using the new Zend_Log instead of shown on a production website ![]()
I can see the value of this enhancement and how it is a building-block toward hierarchies of controllers, etc. It also solves cases of the 'headers already sent' issue.
My only concern is that this will be a significant backward-compatibility break.
If a developer upgrades ZF but neither sets outputBuffering(false) or echoes the response body, will
will find their MVC app outputs nothing, right?
| "Official Zend Comment" Okay, the benefits to testability have persuaded me that this change is worth the BC breakage. This provides value matching that of the instantiable Request object introduced in ZF 0.2. This enhancement is approved for development in the incubator. Optionally you may develop in the core directory, in a svn branch off of the trunk. I request that you write a manual section addressing testing methodology for MVC applications, and how to use the Request and Response objects to write unit tests for web applications. |
ZF Home Page
Code Browser
Wiki Dashboard
I'm highly in favor of this!