Added by Matthew Weier O'Phinney, last edited by Matthew Weier O'Phinney on Mar 03, 2007  (view change) show comment

Labels

 
(None)

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'm highly in favor of this!

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

Posted by Gavin at Mar 08, 2007 16:11

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?

By default, Zend_Controller_Front::dispatch() calls $response->sendOutput(), which sends the aggregated body content and headers. So, in the end, the only difference is when content is sent.

"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.

I will address unit testing of MVC applications in the documentation as I revamp and reorganize the docs for 0.9.