$this->getRequest()->isPost() vs. ($_SERVER['REQUEST_METHOD'] == 'POST')

[HMunroe]

I just read this blog post from Matthew, and saw the link to the QuickStart:

* http://framework.zend.com/wiki/display/ZFDEV/Official+ZF+QuickStart

I found something that I find disturbing. In the form handler, I saw this:

if ($this->getRequest()->isPost()) {...

(this is in the Build a Form section)

Isn't this a little too overcomplicated ? I also like the well-arranged and tidy OOP syntax, but this seems too much for me. I don't mean to criticize, but I want to figure out what's the logic behind a line of code like that. What would justify the extra cycles for stacking the function calls, and passing the request object, against plain old "equals" check , like:

if ($_SERVER['REQUEST_METHOD'] == 'POST') { ...

I understand that there are a lot of ways to do a job, but in this case this doesn't seem like a "best practice" to me.

What do you think ?

[weierophinney]

-- HMunroe <harry.munroe@...> wrote
(on Wednesday, 27 August 2008, 09:53 AM -0700):

> I just read this
> http://weierophinney.net/matthew/archives/184-Speaking-at-ZendCon-2008.html
> blog post  from Matthew, and saw the link to the QuickStart:
>
> *  http://framework.zend.com/wiki/display/ZFDEV/Official+ZF+QuickStart
> http://framework.zend.com/wiki/display/ZFDEV/Official+ZF+QuickStart 
>
> I found something that I find disturbing. In the form handler, I saw this:
>
> if ($this->getRequest()->isPost()) {...
>
> (this is in the
> http://framework.zend.com/wiki/display/ZFDEV/Official+ZF+QuickStart#OfficialZFQuickStart-BuildaForm
> Build a Form  section)
>
> Isn't this a little too overcomplicated ? I also like the well-arranged and
> tidy OOP syntax, but this seems too much for me. I don't mean to criticize,
> but I want to figure out what's the logic behind a line of code like that.
> What would justify the extra cycles for stacking the function calls, and
> passing the request object, against plain old "equals" check , like:
>
> if ($_SERVER['REQUEST_METHOD'] == 'POST') { ...
>
> I understand that there are a lot of ways to do a job, but in this case this
> doesn't seem like a "best practice" to me.
>
> What do you think ?

A couple of things.

First, despite it's "verbosity", the ZF line is shorter than the one you
suggest. :)

Now, snarkiness aside, there are some good reasons behind this.

Sometimes the obvious and simple solutions simply are not portable, or
would circumvent custom logic the developer may need to utilize.

So, let's look at the examples above.

First, you _can_ use the $_request property directly. However, if you
ever modify getRequest() in your class or in a custom base controller
class, then you may be accessing the wrong property or overriding
necessary business logic. For this reason, we recommend using
getRequest() to grab the request object. (This is good OOP practice,
btw.)

Next, using isPost() is more portable than using
$_SERVER['REQUEST_METHOD']. The reasons are that your web server may or
may not populate this environment variable, and for testing. With
testing, we allow you to specifically set the request method -- $_SERVER
is never modified in this case. This gives you the ability to test your
applications without needing a web server involved.

Hope this answers your questions.

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend Framework           | http://framework.zend.com/

[HMunroe]

Matthew Weier O'Phinney-3 wrote:

First, you _can_ use the $_request property directly. However, if you
ever modify getRequest() in your class or in a custom base controller
class, then you may be accessing the wrong property or overriding
necessary business logic. For this reason, we recommend using
getRequest() to grab the request object. (This is good OOP practice,
btw.)

I understand that, and I am OK with it (and I welcome all the new features added like the params stuff), but the example I gave is with $_SERVER and not $_REQUEST. And it is a good OOP practice, but in this case is a way too much for something so simple.

Matthew Weier O'Phinney-3 wrote:

Next, using isPost() is more portable than using
$_SERVER['REQUEST_METHOD']. The reasons are that your web server may or
may not populate this environment variable, and for testing. With
testing, we allow you to specifically set the request method -- $_SERVER
is never modified in this case. This gives you the ability to test your
applications without needing a web server involved.

I see, it's cool.

[weierophinney]

-- HMunroe <harry.munroe@...> wrote
(on Thursday, 28 August 2008, 05:49 AM -0700):

> Matthew Weier O'Phinney-3 wrote:
> >
> > First, you _can_ use the $_request property directly. However, if you
> > ever modify getRequest() in your class or in a custom base controller
> > class, then you may be accessing the wrong property or overriding
> > necessary business logic. For this reason, we recommend using
> > getRequest() to grab the request object. (This is good OOP practice,
> > btw.)
> >
> I understand that, and I am OK with it (and I welcome all the new features
> added like the params stuff), but the example I gave is with $_SERVER and
> not $_REQUEST. And it is a good OOP practice, but in this case is a way too
> much for something so simple.

I mainly highlighted that as I anticipated others raising the question
of why getRequest() is used over _request.

BTW, $_REQUEST != the request object. The request object encapsulates a
variety of sources, including the various sources used by $_REQUEST, but
also $_SERVER, $_ENV, etc. This simplifies access to a variety of
sources, as well as provides abstraction and encapsulation, allowing
you to seamlessly switch between environments.

It may seem overkill for "something so simple", but often using $_SERVER
is oversimplification and non-portable.

> Matthew Weier O'Phinney-3 wrote:
> > Next, using isPost() is more portable than using
> > $_SERVER['REQUEST_METHOD']. The reasons are that your web server may or
> > may not populate this environment variable, and for testing. With
> > testing, we allow you to specifically set the request method -- $_SERVER
> > is never modified in this case. This gives you the ability to test your
> > applications without needing a web server involved.
> >
> I see, it's cool.

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend Framework           | http://framework.zend.com/

[HMunroe]

Matthew Weier O'Phinney-3 wrote:

BTW, $_REQUEST != the request object. The request object encapsulates a
variety of sources, including the various sources used by $_REQUEST, but
also $_SERVER, $_ENV, etc. This simplifies access to a variety of
sources, as well as provides abstraction and encapsulation, allowing
you to seamlessly switch between environments.

I am sorry, but I am not sure I follow -- what *other* environments ? Are you talking about CLI applications ?

Otherwise, yeah, I am familiar w/ the request object from ZF, and all the ideas applied there and it's cool. Sometimes I wonder what PHP would look like if the superglobals are made read-only.

[weierophinney]

-- HMunroe <harry.munroe@...> wrote
(on Thursday, 28 August 2008, 08:34 AM -0700):

> Matthew Weier O'Phinney-3 wrote:
> >
> > BTW, $_REQUEST != the request object. The request object encapsulates a
> > variety of sources, including the various sources used by $_REQUEST, but
> > also $_SERVER, $_ENV, etc. This simplifies access to a variety of
> > sources, as well as provides abstraction and encapsulation, allowing
> > you to seamlessly switch between environments.
>
> I am sorry, but I am not sure I follow -- what *other* environments ? Are
> you talking about CLI applications ?

CLI, GTK, and, most importantly, unit tests, which are typically run via
CLI, but which usually setup their own environment. In the case of
Zend_Test_PHPUnit, we have stub request and response objects that are
used as drop-in replacements for the standard versions -- and which
allow you to set the values for the various data sources.

> Otherwise, yeah, I am familiar w/ the request object from ZF, and all the
> ideas applied there and it's cool. Sometimes I wonder what PHP would look
> like if the superglobals are made read-only.

--
Matthew Weier O'Phinney
Software Architect       | matthew@...
Zend Framework           | http://framework.zend.com/