d11wtq wrote:I do think that the Response stuff should be handled by a separate class, which is held as an instance in the front controller though. I'm not familiar with the ZF much and probably won't learn it yet unless I'm forced to through work. I'll look at it more in 6 months time maybe.
The more I pick it apart and roll my own solution, the more I dislike Zend. Admittedly, I have adopted some ideas such as class loader, but have refactored that into the application layer not the library.
Why do you feel the response should as an instance inside front controller? I personally no advantage.
1) Keeping it in a registry keeps the API of the front simpler.
2) Keeping it in a registry keeps the front more resuable.
The latter I better explain. Zend strives for flexibility. It's own article on response objects says so:
http://framework.zend.com/wiki/display/ ... nse+Object
See last sentance:
Reasons to subclass the response object include modifying how output is returned based on the request environment (e.g., not sending headers for CLI or PHP-GTK requests), adding functionality to return a final view based on content stored in named segments, etc
What response is there GTK applications. The Zend response object also stores exceptions, but I'd rather handle that explicitly myself inside index.php as a way to centralize error logging - personal preference. I'm not criticizing Zend, just trying to understand the reasoning behind keeping a part of the front API as opposed to keeping it in the registry. As it stands right now, based on personal taste, I would opt for a registry to store my response object.