Issues

ZF-10868: Refactorization of Zend_Controller_Response_Abstract to migrate HTTP-specific code to Zend_Controller_Repsonse_Http

Description

Let me start with my use case:

I am working on creating a hybrid application that will serve both HTTP and CLI requests, and responses. As such, I am building the application in parallel, but being very careful to keep my requests/responses separate. As such, I have begun to notice errors in the command line due to headers already being sent. I am not exactly sure why I would be getting this type of error, as it is not something that I can cause to happen every time that I send output (output could be coming from controller plugins, Zend_Log at various points in code, controllers, or views -- I am currently working on code, so I am also randomly using echo, print, Zend_Debug, or something similar).

This leads to why I'm writing this ticket: Despite the randomness of the problems I am encountering, I was inspired to investigate the inner-workings of Zend_Controller_Response_Abstract and friends. During my investigation, I found that Zend_Controller_Response_Abstract handles all of the HTTP-specific code, while Zend_Controller_Response_Http is nothing more than an alias for the abstract class it derives. The Zend_Controller_Response_Cli is derived from the abstract class, which in turn means that it inherits all of that HTTP-specific code.

I feel that this is a less-than-optimal implementation, and I am proposing a rather comprehensive patch that will truly separate out the response object based on "types". I feel that in doing so, the development community can benefit by being able to more easily create response objects of various types. Basically this patch will provide a new method in a couple of places that will help developers determine what type of response object they are working with:

Zend_Controller_Front::isResponse(string $type, string $namespace) Zend_Controller_Action_Helper_Abstract::isResponse(string $type, string $namespace) Zend_Controller_Action::isResponse(string $type, string $namespace)

The $type is the main part of what defines a response object. In the current Zend Framework, there is a choice between 'http' and 'cli'. The $namespace - which defaults to "Zend_Controller_Response", and is optional - allows for the ability to expand response objects beyond the Zend Framework core.

While I understand the implications that this patch brings with it, I feel that it is as backward-compatible as possible. However, I cannot guarantee that, and I would appreciate any and all advice from the more-experienced contributors on how I might be able to improve this patch for inclusion.

Comments

It should be noted that for every method that I moved out of Zend_Controller_Response_Abstract and into Zend_Controller_Response_Http, I've searched through the entire core code base to ensure that it is being used properly (i.e., there should be no Fatal Errors due to using the wrong object type).

While I completely understand the motivation for this, the problem is that if anyone has extended Zend_Controller_Response_Abstract (instead of _Http), the methods will then no longer be available -- which is a fairly major backwards-compatibility break.

ZF2 will have both separate interfaces as well as objects for HTTP-specific requests and responses, which is why I'm marking this as postponed.