|
Administrator
|
Hey, all --
As I've been creating unit tests for the new/refactored components coming in, I've been doing some thinking in a few areas. One area involves how to handle forwarding to another action. Some of us had discussed passing back a boolean true from the action, pre-, or postDispatch methods in order to indicate that another action has been requested. I have a problem with this idea as there may be a number of situations where a return value may be desired. Additionally, I've been considering usage of a response object; using one would cause some huge changes later. So, something I considered: what if we create a flag in the request object indicating 'dispatched'? Then, if it's not toggled on, we know that the request in the object needs to be dispatched still; otherwise, we know that the request has been processed. Here's what I'm envisioning: $request->setDispatched(false); // not yet dispatched $request->setDispatched(true); // already dispatched, or skip $request->isDispatched(); // has it been dispatched? As a class skeleton: interface Zend_Controller_Request_Interface { public function getControllerName(); public function setControllerName($value); public function getActionName(); public function setActionName($value); public function getParam($key); public function setParam($key, $value); public function getParams(); public function setParams($array); public function setDispatched($flag); public function isDispatched(); } /** * We can probably create the basic functionality in the * abstract class for all of the methods; just doing the dispatched * methods here abstract class Zend_Controller_Request_Abstract implements Zend_Controller_Request_Interface { protected $_dispatched = false; public function setDispatched($flag) { $this->_dispatched = $flag ? true : false; } public function isDispatched() { return $this->_dispatched; } } Then, in Zend_Controller_Front::dispatch()'s dispatch loop: do { $request->setDispatched(true); // notify plugins that a dispatch is about to occur $this->_plugins->preDispatch($request); // skip requested action if preDispatch() has reset it if (!$request->isDispatched()) { continue; } $response = $this->getDispatcher()->dispatch($request); // notify plugins that the dispatch has finish $this->_plugins->postDispatch($request); } while (!$request->isDispatched()); Zend_Controller_Action::_forward() would look something like this then: protected function _forward($controller, $action, $params = array()) { $this->_request->setControllerName($controller); $this->_request->setActionName($action); $this->_request->setParams($params); $this->_request->setDispatched(false); } Thoughts? -- Matthew Weier O'Phinney PHP Developer | [hidden email] Zend - The PHP Company | http://www.zend.com/ |
|
On first look I like it a lot. I think actually using it will make it
clear whether this is the cleanest way, but I think it may be. Perhaps it should be setDispatched($flag=true) if that is the direction that will be set most of the time. Matthew Weier O'Phinney wrote: > Hey, all -- > > As I've been creating unit tests for the new/refactored components > coming in, I've been doing some thinking in a few areas. > > One area involves how to handle forwarding to another action. > > Some of us had discussed passing back a boolean true from the action, > pre-, or postDispatch methods in order to indicate that another action > has been requested. I have a problem with this idea as there may be a > number of situations where a return value may be desired. Additionally, > I've been considering usage of a response object; using one would cause > some huge changes later. > > So, something I considered: what if we create a flag in the request > object indicating 'dispatched'? Then, if it's not toggled on, we know > that the request in the object needs to be dispatched still; otherwise, > we know that the request has been processed. > > Here's what I'm envisioning: > > $request->setDispatched(false); // not yet dispatched > $request->setDispatched(true); // already dispatched, or skip > $request->isDispatched(); // has it been dispatched? > > As a class skeleton: > > interface Zend_Controller_Request_Interface > { > public function getControllerName(); > public function setControllerName($value); > public function getActionName(); > public function setActionName($value); > public function getParam($key); > public function setParam($key, $value); > public function getParams(); > public function setParams($array); > public function setDispatched($flag); > public function isDispatched(); > } > > /** > * We can probably create the basic functionality in the > * abstract class for all of the methods; just doing the dispatched > * methods here > abstract class Zend_Controller_Request_Abstract implements Zend_Controller_Request_Interface > { > protected $_dispatched = false; > > public function setDispatched($flag) > { > $this->_dispatched = $flag ? true : false; > } > > public function isDispatched() > { > return $this->_dispatched; > } > } > > Then, in Zend_Controller_Front::dispatch()'s dispatch loop: > > do { > $request->setDispatched(true); > > // notify plugins that a dispatch is about to occur > $this->_plugins->preDispatch($request); > > // skip requested action if preDispatch() has reset it > if (!$request->isDispatched()) { > continue; > } > > $response = $this->getDispatcher()->dispatch($request); > > // notify plugins that the dispatch has finish > $this->_plugins->postDispatch($request); > } while (!$request->isDispatched()); > > Zend_Controller_Action::_forward() would look something like this then: > > protected function _forward($controller, $action, $params = array()) > { > $this->_request->setControllerName($controller); > $this->_request->setActionName($action); > $this->_request->setParams($params); > $this->_request->setDispatched(false); > } > > Thoughts? > > |
|
Christopher Thompson wrote:
> On first look I like it a lot. I think actually using it will make it > clear whether this is the cleanest way, but I think it may be. Perhaps > it should be setDispatched($flag=true) if that is the direction that > will be set most of the time. Yes, I like it also. Good work, Matthiew. -- Michael Minicki aka Martel Valgoerad | [hidden email] | http://aie.pl/martel.asc =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Generosity is giving more than you can, and pride is taking less than you need." -- Kahlil Gibran |
|
In reply to this post by weierophinney
Matthew Weier O'Phinney wrote:
> Here's what I'm envisioning: > > $request->setDispatched(false); // not yet dispatched > $request->setDispatched(true); // already dispatched, or skip > $request->isDispatched(); // has it been dispatched? > At first sight, it looks good. Seems clean and not intrusive. My only vague concern is that it increases the scope of responsibility of the request object. Do we have a definitive definition of what the request object is and is not responsible for? Regards, Rob... |
|
Administrator
|
-- Rob Allen <[hidden email]> wrote
(on Thursday, 19 October 2006, 08:40 AM +0100): > Matthew Weier O'Phinney wrote: > > > Here's what I'm envisioning: > > > > $request->setDispatched(false); // not yet dispatched > > $request->setDispatched(true); // already dispatched, or skip > > $request->isDispatched(); // has it been dispatched? > > > > At first sight, it looks good. Seems clean and not intrusive. > > My only vague concern is that it increases the scope of responsibility > of the request object. Do we have a definitive definition of what the > request object is and is not responsible for? There are actually a variety of flavors for the request object. The one used with the controllers needs to follow only the following interface: interface Zend_Controller_Request_Interface { public function getControllerName(); public function setControllerName($value); public function getActionName(); public function setActionName($value); public function getParam($key); public function setParam($key, $value); public function getParams(); public function setParams($array); // proposed addition: public function setDispatched($flag = true); public function isDispatched(); } Basically, the request object the controller uses only needs to be able to store the controller name, action name, and parameters necessary to perform an action; I'm only proposing we have it additionally keep track of whether or not the request has been dispatched. It's a pretty minimal interface. The default request object, Zend_Controller_Request_Http, will extend Zend_Http_Request and implement the above interface; this makes it aware of the HTTP environment in the scope of its duties. As such, it's a bit bigger in scope, but not terribly so. -- Matthew Weier O'Phinney PHP Developer | [hidden email] Zend - The PHP Company | http://www.zend.com/ |
|
Administrator
|
In reply to this post by weierophinney
Based on the feedback, I'll add this to the proposal as well as to the interface
class. Thanks for the review! -- Matthew Weier O'Phinney <[hidden email]> wrote (on Wednesday, 18 October 2006, 04:54 PM -0400): > Hey, all -- > > As I've been creating unit tests for the new/refactored components > coming in, I've been doing some thinking in a few areas. > > One area involves how to handle forwarding to another action. > > Some of us had discussed passing back a boolean true from the action, > pre-, or postDispatch methods in order to indicate that another action > has been requested. I have a problem with this idea as there may be a > number of situations where a return value may be desired. Additionally, > I've been considering usage of a response object; using one would cause > some huge changes later. > > So, something I considered: what if we create a flag in the request > object indicating 'dispatched'? Then, if it's not toggled on, we know > that the request in the object needs to be dispatched still; otherwise, > we know that the request has been processed. > > Here's what I'm envisioning: > > $request->setDispatched(false); // not yet dispatched > $request->setDispatched(true); // already dispatched, or skip > $request->isDispatched(); // has it been dispatched? > > As a class skeleton: > > interface Zend_Controller_Request_Interface > { > public function getControllerName(); > public function setControllerName($value); > public function getActionName(); > public function setActionName($value); > public function getParam($key); > public function setParam($key, $value); > public function getParams(); > public function setParams($array); > public function setDispatched($flag); > public function isDispatched(); > } > > /** > * We can probably create the basic functionality in the > * abstract class for all of the methods; just doing the dispatched > * methods here > abstract class Zend_Controller_Request_Abstract implements Zend_Controller_Request_Interface > { > protected $_dispatched = false; > > public function setDispatched($flag) > { > $this->_dispatched = $flag ? true : false; > } > > public function isDispatched() > { > return $this->_dispatched; > } > } > > Then, in Zend_Controller_Front::dispatch()'s dispatch loop: > > do { > $request->setDispatched(true); > > // notify plugins that a dispatch is about to occur > $this->_plugins->preDispatch($request); > > // skip requested action if preDispatch() has reset it > if (!$request->isDispatched()) { > continue; > } > > $response = $this->getDispatcher()->dispatch($request); > > // notify plugins that the dispatch has finish > $this->_plugins->postDispatch($request); > } while (!$request->isDispatched()); > > Zend_Controller_Action::_forward() would look something like this then: > > protected function _forward($controller, $action, $params = array()) > { > $this->_request->setControllerName($controller); > $this->_request->setActionName($action); > $this->_request->setParams($params); > $this->_request->setDispatched(false); > } > > Thoughts? > > -- > Matthew Weier O'Phinney > PHP Developer | [hidden email] > Zend - The PHP Company | http://www.zend.com/ > -- Matthew Weier O'Phinney PHP Developer | [hidden email] Zend - The PHP Company | http://www.zend.com/ |
| Powered by Nabble | Edit this page |
