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

Issue Type: Bug Created: 2010-12-26T21:31:12.000+0000 Last Updated: 2010-12-27T06:30:54.000+0000 Status: Postponed Fix version(s): Reporter: Ken Stanley (dohpaz) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Controller

  • Zend_Layout
  • Zend_OpenId
  • Zend_Test_PHPUnit
  • Zend_Tool
  • Zend_View
  • Zend_Wildfire

Related issues: Attachments: - ZF-10868.patch


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.


Posted by Ken Stanley (dohpaz) on 2010-12-26T21:34:14.000+0000

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

Posted by Matthew Weier O'Phinney (matthew) on 2010-12-27T06:30:52.000+0000

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.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.