Quantcast

Ideas about forwarding to successive actions

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Ideas about forwarding to successive actions

weierophinney
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Ideas about forwarding to successive actions

Christopher Thompson-2
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?
>
>  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Ideas about forwarding to successive actions

Martel
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Ideas about forwarding to successive actions

akrabat
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...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Ideas about forwarding to successive actions

weierophinney
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/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: Ideas about forwarding to successive actions

weierophinney
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/
Loading...