Page 1 of 1

Posted: Wed Jul 18, 2007 3:01 am
by alex.barylski
A zend related question so I figured I would throw it in here.

Zend and it's response object. Why is it explicitly part of Front controller? Seems to me it would make more sense to store it in the registry and update headers, content, etc.

At least with the function:

Code: Select all

$front->returnResponse(true);
Perhaps the article I just read is outdated and this is no longer the case, but considering the "total" flexibility that Zend seems to strive for in terms of KISS and abstraction, it especially seems odd that Zend would use this approach.

What are the reasons/benefits in using or having the front return a response object as opposed to keeping that in the registry?

Posted: Wed Jul 18, 2007 7:20 am
by John Cartwright
Hockey wrote:A zend related question so I figured I would throw it in here.
:evil:

Topic Split.

Posted: Wed Jul 18, 2007 8:55 am
by Jenk
Hockey wrote:What are the reasons/benefits in using or having the front return a response object as opposed to keeping that in the registry?
The front controller is the entry point of the application. Metaphorically, it's the front door to the house.

Posted: Wed Jul 18, 2007 2:53 pm
by Chris Corbyn
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.

Posted: Wed Jul 18, 2007 4:48 pm
by alex.barylski
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.

Posted: Wed Jul 18, 2007 5:00 pm
by Chris Corbyn
Hockey wrote:Why do you feel the response should as an instance inside front controller? I personally no advantage.
Sorry, not necessarily only in the front controller. Request and Response make appropriate singletons anyway. Would you ever send two responses? ;) Holiding request and response in properties inside any aspect of the controller layer is purely convenient.

Posted: Wed Jul 18, 2007 8:58 pm
by Begby
If the front controller requires the response object, how does it help or make it more reuseable if its stored in a registry? You will still need to pass it to the front controller and the controller will use it just as before. Also, the only thing that should be accessing the response is controller methods, not your model or anything. So passing that in a registry to any other classes is pointless.

Secondly, if you really want to you can store it in a registry, Zend isn't preventing you at all. You can initialize any subclassed response object that you want, put it in the registry, then pass the response into dispatch() or setResponse(). I really don't know what benefit that would be though unless you wanted to run some methods on the response before calling dispatch().

Posted: Thu Jul 19, 2007 4:54 pm
by alex.barylski
Begby wrote:If the front controller requires the response object, how does it help or make it more reuseable if its stored in a registry? You will still need to pass it to the front controller and the controller will use it just as before. Also, the only thing that should be accessing the response is controller methods, not your model or anything. So passing that in a registry to any other classes is pointless.

Secondly, if you really want to you can store it in a registry, Zend isn't preventing you at all. You can initialize any subclassed response object that you want, put it in the registry, then pass the response into dispatch() or setResponse(). I really don't know what benefit that would be though unless you wanted to run some methods on the response before calling dispatch().
Thats a good point. However nothing is touching my response except controllers and index.php to echo the results to screen.

I am not using Zend, but modelling my own implementation after it and others I have looked into. Keeping the API simple is impetus. Zend confused me with it's use of a method in the front to fetch response because it's target audience is much greater than my own. GTK applications do not need a response object - exception to deal with exceptions possibly.

I'm following an "If you don't need, don't add it" philosophy in designing my own. I already pass around a registry object which could also store a response and thus eliminate the need for additional methods in the front, binding the the two objects. Your boldified argument is something I did not consider. However I don't believe it is enough to sway my decision in using an explicit method in the front as opposed to using a generic registry - which I already use. I will certainly add that restriction to my list of standards though - don't touch the response except in controllers. :)

Posted: Fri Jul 20, 2007 5:32 am
by Chris Corbyn
Something common to all controller components is the need to access Request and Response.

Code: Select all

abstract class AbstractController {
  protected $request;
  protected $response;
  public function doRedirect() {
    $this->response->setHeader("Location", ...);
    $this->response->flushHeaders();
    exit();
  }
  public function doForward() {
    $this->request->forward( ... );
  }
}

Code: Select all

class FrontController extends AbstractController {
  public function dispatch() {
    // ... snip ...
    if ($this->sendResponse) {
      //...
    }
  }
}
Makes sense to me. The FrontController is ultimately the thing that will finally send the response, so what else do you tell not to send a response, or to send one?

I originally misread the first post and didn't realise you were referring to something which clearly belongs in the front controller.