SitePoint Sponsor

User Tag List

Results 1 to 24 of 24

Hybrid View

  1. #1
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Request object? Or use Controller?

    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

  2. #2
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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...

  3. #3
    SitePoint Member
    Join Date
    Aug 2005
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #4
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  5. #5
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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.

  6. #6
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    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.
    Business as usual is off the menu folks, ...

  7. #7
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    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

  8. #8
    SitePoint Member
    Join Date
    Aug 2005
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    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.

  9. #9
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by i_m_making_a_cms
    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

  10. #10
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by i_m_making_a_cms
    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?

  11. #11
    SitePoint Zealot Serberus's Avatar
    Join Date
    Oct 2005
    Location
    Herts, UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    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.

  12. #12
    SitePoint Member
    Join Date
    Aug 2005
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    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.

  13. #13
    Web-coding NINJA! silver trophy beetle's Avatar
    Join Date
    Jul 2002
    Location
    Dallas, TX
    Posts
    2,900
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    beetle a.k.a. Peter Bailey
    blogs: php | prophp | security | design | zen | software
    refs: dhtml | gecko | prototype | phpdocs | unicode | charsets
    tools: ide | ftp | regex | ffdev




  14. #14
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    163
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  15. #15
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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?
    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.

  16. #16
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    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.

  17. #17
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    423
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    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?

  18. #18
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's an abridged code snippet:

    PHP Code:
    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.

  19. #19
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    163
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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?

  20. #20
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  21. #21
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > 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

  22. #22
    SitePoint Member
    Join Date
    Aug 2005
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    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.

  23. #23
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by i_m_making_a_cms
    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.

  24. #24
    SitePoint Evangelist
    Join Date
    Aug 2004
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    I disagree

    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

    PHP Code:
    #/calendar/day/year/month/day#/
    $viewhelper = new CalendarViewHelper();
    $viewhelper->setDayMonthYear( array($year$month$day) );
    $viewhelper->setUserNameSystemConfig::$SubdomainBrowsing );
    $viewhelper->setViewSize('large');

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


    all chainsdecoratorscompositesCoR  will use 
    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.
    PHP Code:
    $chain Cache_Database($handleCache_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 ]


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •