Request object? Or use Controller?

[mwmitchell]

I'm building a mvc application. I'd like to make it as simple and independent as possible. I'm wondering how necessary it would be to create a Request object that encapsulates $_GET, $_POST and $_COOKIE?

I'm tempted to simply add methods to the controller base object:

Controller:aramGET()
Controller:aramPOST()
Controller:aramCOOKIE()
Controller:aramPATH()

I've also considered just using Controller:aram(), for $_GET, $_POST and $_SERVER['PATH_INFO'], where $_POST would override $_GET... and $_GET would override $_SERVER['PATH_INFO']. Controller::storage() could be for for $_COOKIE.

Is it so wrong to make it as simple as possible? I mean it's MVC, not RMVCR right?

- matt

[33degrees]

MVC is a seperation of layers, there's no obligation for each layer to be a single class (although that's certainly a way to do it), and it's very common to have multiple classes in each layer. Also, ask yourself what's really simpler, a single class that has two different responsibilities, or two classes that have one each? Classes that do too much are generally considered a bad thing...

[i_m_making_a_cms]

The way I see it, encapsulating Request data in the Controller is pushing the Controller towards God status. It doesn't make sense to me semantically.

On the other hand, I'm not a big fan of Request objects. The ones I've seen don't seem much more than glorified data containers; perhaps with a redirect method thrown in for good measure.

$this->request = $_REQUEST;

usually suffices for me, but I generally avoid abstractions that I don't need or don't think I'll need in the future.

[mwmitchell]

Right. My main concern is name space issues and just having too many objects. I think I've decided to have separate objects, but will wait to see what happens.

On the same token as keeping it simple.... If I'm building a very simple controller framework.... does it seem weird to put all of the classes in one file and name the file "framework.inc.php" or some such? I realize that testing could be a problem with that setup... but not to that point yet.

[beetle]

I'd be curious to hear your opinion on this

http://www.sitepoint.com/forums/show...7&postcount=14

There's a request object in the root post you might be interested in as well.

[33degrees]

Right. My main concern is name space issues and just having too many objects. I think I've decided to have separate objects, but will wait to see what happens.

Too many objects can be a problem, the trick is to find the balance.

While the responsibilities of a request object can easily be done by the controller, I think it's a good candidate for a seperate object because the abstraction is easy to grasp, and it's responsibilities are quite clear, and easy to seperate from a controller's. I also think that, if you're doing TDD, it's better to have the request be seperate and mockable, rather than inserting data into the super globals.

[Galo]

Too many objects can be a problem, the trick is to find the balance.

While the responsibilities of a request object can easily be done by the controller, I think it's a good candidate for a seperate object because the abstraction is easy to grasp, and it's responsibilities are quite clear, and easy to seperate from a controller's. I also think that, if you're doing TDD, it's better to have the request be seperate and mockable, rather than inserting data into the super globals.

Yeah right, indeed, ying yang, i always tend to create a factory where i can get my object from, that way you can monitor what objects are active in your application.

[i_m_making_a_cms]

On the same token as keeping it simple.... If I'm building a very simple controller framework.... does it seem weird to put all of the classes in one file and name the file "framework.inc.php" or some such? I realize that testing could be a problem with that setup... but not to that point yet.

Not weird to me at all. I do this during development AND deployment; development, because I find it convenient to have all my core classes in one editor window, deployment, because I like to keep includes to a minimum. If you can cut out a half dozen includes this way I think the performance benefits outweigh any drawbacks. In fact, if the framework is for your own personal use, I can't see any drawbacks at all.

[BerislavLopac]

On the other hand, I'm not a big fan of Request objects. The ones I've seen don't seem much more than glorified data containers; perhaps with a redirect method thrown in for good measure.

I'm just implementing intercepting filters, and I'm considering using a Request class that would get operated on and modified by the filter chain. Once it is out of the chain it contains a filtered state that would have all the updated data, such as login user etc.

Opinions?

[Serberus]

I'm just implementing intercepting filters, and I'm considering using a Request class that would get operated on and modified by the filter chain. Once it is out of the chain it contains a filtered state that would have all the updated data, such as login user etc.

Opinions?

I've seen this mentioned as one of the advantages to using a request object, you can manipulate (clean) the data and pass it safely to your domain objects while not modifying the source (i.e. the super globals). You can then return the unmodified (but escaped) data to the user if needed.

[EscapeYourMind]

Just a quick question about the intercepting filters. I understand the general theory behind them (pre and post processing), but what kind of actions do you do inside of your intercepting filters? I can not really think of anything that would need to be explicitly run before or after all parts of the application are run.

[33degrees]

Just a quick question about the intercepting filters. I understand the general theory behind them (pre and post processing), but what kind of actions do you do inside of your intercepting filters?

So far, I've used them for authentication (redirecting a user to a login page if they're not logged in), authorisation (redirecting to an error page if the use tries to do something they don't have the rights to do), and logging (keeping a detailed trace of who did what when). Since all of these task needed to occur on each call regardless of what action was called, an intercepting filter was the best solution.

[BerislavLopac]

So far, I've used them for authentication (redirecting a user to a login page if they're not logged in), authorisation (redirecting to an error page if the use tries to do something they don't have the rights to do), and logging (keeping a detailed trace of who did what when). Since all of these task needed to occur on each call regardless of what action was called, an intercepting filter was the best solution.

Exactly. Other uses are server-side input data verification/validation (checking if required fields were entered with appropriate values), input data cleaning (e.g. unescaping of input values, value conversions -- e.g. from 2006-07-07 to a Linux timestamp -- etc.

[mwmitchell]

Not weird to me at all. I do this during development AND deployment; development, because I find it convenient to have all my core classes in one editor window, deployment, because I like to keep includes to a minimum. If you can cut out a half dozen includes this way I think the performance benefits outweigh any drawbacks. In fact, if the framework is for your own personal use, I can't see any drawbacks at all.

I agree! Sometimes it's just so much easier to scroll up and down one page instead of 6 or 7. And I guess it could speed it up not having to do all of those includes. The classes are part of a framework and pretty much depend on one another.

- matt

[mwmitchell]

Too many objects can be a problem, the trick is to find the balance.

While the responsibilities of a request object can easily be done by the controller, I think it's a good candidate for a seperate object because the abstraction is easy to grasp, and it's responsibilities are quite clear, and easy to seperate from a controller's. I also think that, if you're doing TDD, it's better to have the request be seperate and mockable, rather than inserting data into the super globals.

That's what I've decided to do. My base controller is already handling a lot, no need to muck it up.

Thanks for all of the feedback.

- matt

[skinny monkey]

Exactly. Other uses are server-side input data verification/validation (checking if required fields were entered with appropriate values), input data cleaning (e.g. unescaping of input values, value conversions -- e.g. from 2006-07-07 to a Linux timestamp -- etc.

I like these two examples (33 Degrees too) of uses of intercepting filters, but i was wondering where they are used: for instance, are they added like decorators to the request object, or are the required filters defined in a controller's method? For instance, a controller method that requires the date to be in a linux timestamp will apply the filter itself (within the method - too much responsibility?), or will the filtered data already be passed to the controller method - if so, where do you decide which filters to run on which request?

[33degrees]

Here's an abridged code snippet:

class Controller {

    function process($request, $response) {
        $this->request = $request;
        $this->params = $request->parameters;
        $this->response = $response;

        if (isset($this->params['action'])) {
            $this->action_name = $this->params['action'];
        } else {
            $this->action_name = 'index';
        }

        $filter_result = $this->filter_chain->call_before($this->action_name);

        if (!$filter_result || $this->has_performed()) {
            return $this->response;    
            
        }

        if (method_exists($this, $this->action_name)) {
            call_user_func(array(&$this, $this->action_name));    
        }

        if (!$this->has_performed()) {
            $this->render();
        }
        
        $this->filter_chain->call_after($this->action_name);
        
        return $this->response;
    }
} 

This process method is called by the dispatcher (front controller), whose purpose is to select the right controller to call and pass it the request and response objects. The has_performed method is true if a redirect or render call is made at any point.

The filter chain executes all the registered filters (which I set in the constructor of the controller), one after the other. If any filter returns false, execution stops; filters can also call a render or a redirect, at which point the rest of the filters will execute, but the called action will not.

Edit:
Forgot to mention: Each filter has a reference to the controller, via which they can modify the request and response, if needed. That's also how they can call redirects or renders.

[EscapeYourMind]

Ok I can see that now. So you basically have your filters in each of your application controllers? From reading around the net I was sort of under the impression that they would be implimented in the front controller so the same filter would be applied to all pages, and I couldn't really think of what use that would be. I can understand having them at the application controller level since each page would be using its own unique set of filters. Do you find that most large applications end up being a combination of MVC within an overall MVC?

[33degrees]

Since each of my controller inherits from a common application controller, filters placed there will apply to all controllers; thus you can have a combination of application wide and controller specific filters. I think this is a more flexible and elegant solution than only having an application wide filterchain, or both application wide and controller specific chains

[i_m_making_a_cms]

I'm just implementing intercepting filters, and I'm considering using a Request class that would get operated on and modified by the filter chain. Once it is out of the chain it contains a filtered state that would have all the updated data, such as login user etc.

Opinions?

Just to clarify, I'm not against Request objects so much as I'm against classes with no meaningful operations other than getters and setters. If you plan to perform various manipulations on the Request data I don't see any reason NOT to encapsulate it. However, it seems most of the implementations I've seen so far have been tacked on for symmetry or some other vague motivation. I really think some PHP developers need a smack and a stern reminder that they're not programming in Java.

[Dr Livingston]

> I really think some PHP developers need a smack and a stern reminder that they're not
> programming in Java.

I don't think that was called for; This issue resides with any number of other languages, not just Java alone. I think the problem that you have highlighted is more down to the lack of experience in both design and object oriented methodologies.

Not blame Java for the worlds ills please

[i_m_making_a_cms]

Not blame Java for the worlds ills please

Not quite sure how you interpreted my last post that way. I have nothing against Java; in fact, I'm more of a Java programmer than anything else. Just pointing out that PHP and Java are two very different beasts and just because they have similarities in syntax, doesn't mean they should be programmed in the same way.

[BerislavLopac]

Just pointing out that PHP and Java are two very different beasts and just because they have similarities in syntax, doesn't mean they should be programmed in the same way.

I agree. PHP has one of the programming world's most versatile implementations of array, and that should be used whenever there is just data involved, with no behavior.

[leblanc]

Depending on the application i may use context object. I think request object is silly if all your doing is $this->_post = $_POST;

Here is an example of a context object more further down this comment

#/calendar/day/year/month/day#/
$viewhelper = new CalendarViewHelper();
$viewhelper->setDayMonthYear( array($year, $month, $day) );
$viewhelper->setUserName( SystemConfig::$SubdomainBrowsing );
$viewhelper->setViewSize('large');

$calendar = new CalendarDay(new GregorianCalculations());
$body.=$calendar->build($viewhelper);


all chains, decorators, composites, CoR  will use a 
viewhelper/context object/visitor   - see my next example: 

I agree. PHP has one of the programming world's most versatile implementations of array, and that should be used whenever there is just data involved, with no behavior.

I would also add:
and not holding configuration information.

Problem that arises if config is in array:
Some applications use an array which are passed to the constructor as to provide another type of functionality. That is bad design because the object is holding to much responsibility. It needs to be broken up into all the options you want.

I think i've seen this in some pear packages also. Cache_Lite i think. This is a way to avoid it.

$chain = Cache_Database($handle, Cache_FileSystem('directory', Cache_Memory()));

//if object
$chain->saveObject($contextObject);
//if non object
$chain->save($contextObject); 

pick and choose by changing the chain. and its a lot easier to maintain as responsiblities are spread correctly. This caching solution is something i just started building... so its not a full implementation of the api yet.


PHP will always continue to keep arrays aka collections/dictionaries alive.
However php will mold into an oop language. php5 was a big step and i'm sure it won't stop there.

Just pointing out that PHP and Java are two very different beasts and just because they have similarities in syntax, doesn't mean they should be programmed in the same way.

this was properly answered by:

I think the problem that you have highlighted is more down to the lack of experience in both design and object oriented methodologies.

Most often php developers have experience with other oo languages. In my case c# to help in areas php can't ... windows forms. [yes i already know about php-gtk ]