SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 36
  1. #1
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Request Objects (A "skeletal" tangent)

    I was reading the skelatal script thread, and was thinking about my own request object - one I am somewhat displeased with.

    I can see the need - take care of magic quotes madness at once, I feel uncomfortable using the superglobals, etc. At the same time, I'm not convinced its entirely nescesary - you could clean up the data with a function of sorts, and just use $_GET['action'] or something. I sort of feel that by doing $Request->getGet('action'), or $Request->getPost('submit') binds the code to data, and worse yet, data that is identified & controled in the CS html. I feel as if the situation forces you to couple your application to data anyways, so why bother?

    At the same time, I struggle with the request vs gpc method - request is obviously the simpler of the two. I think I would rather have them seperated, but I might be paranoid - as long as I properly validate everything, does it actually make a difference? Should the application even care where the variable is from?

    I suppose I could pass all user data in by reference individually isntead of passing a request object, but this seems like a lot of work.

    Whats your thoughts?

  2. #2
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I feel as if the situation forces you to couple your application to data anyways, so why bother?
    It may appear that way, but the way I look at it, is that your not coupling the data to the framework but actually the behaviour of the framework yes? So... If the framework is modular enough in essence, it'd be easy to remove one form of behaviour (component anyone?) and insert a shiny new behaviour, but still be able to use that same data, in the same way that the application using the framework, expects.

    This is why it's better to have a Request class, if that makes sense?

  3. #3
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not really. What do you mean?

  4. #4
    SitePoint Enthusiast
    Join Date
    Feb 2004
    Location
    Montreal
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I tend to approach this problem from a completely different angle. Instead of creating a request object, I use a filter mechanism to apply all of the necessary filtering to the $_GET, $_POST, etc. superglobals before they are accessed. By filter, I mean a block of code that is executed before any command-specific code is run. I have not yet run into any problems with this approach and wonder why there is the need to encapsulate access to the request superglobals in a request object.

    Oh and Dr., I didn't quite follow your reply either. Could you rephrase that please?

  5. #5
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I can see the need - take care of magic quotes madness at once, I feel uncomfortable using the superglobals, etc. At the same time, I'm not convinced its entirely nescesary - you could clean up the data with a function of sorts, and just use $_GET['action'] or something. I sort of feel that by doing $Request->getGet('action'), or $Request->getPost('submit') binds the code to data, and worse yet, data that is identified & controled in the CS html. I feel as if the situation forces you to couple your application to data anyways, so why bother?
    I think for me the level playing field regarding both magic quotes and GPC make it worthwhile. I find having as single $request->get('myparam') function simplifies the code. When I don't care whether it is get or post I don't have to think about it. When I do care I find $request->isPost() clearer. It also makes a central point that you can very easily do app specific things that are sitewide.
    Christopher

  6. #6
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Super Phil
    Whats your thoughts?
    With a request object encapsulating user input, the input type is hidden from the rest of the app. With:
    PHP Code:
       $request->getFoo(); 
    .."foo" could have come from anywhere. Swapping out request objects would for example allow an easy switch from http to CLI (other changes would also be required). If you refer to GPC superglobals throughout the app, you might have presentation bleeding into the domain.

    A "request gateway" (there would be other classes at work behind the request object) brings all the validation checks into one location rather than, possibly, dispersed throughout the app wherever you access a superglobal. I think that helps to promote a more methodical approach to input validation making it less likely that you'll forget to check something somewhere. getFoo can just return null, false or etc if the value fails to validate: bad data is never allowed through.

  7. #7
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A "request gateway" (there would be other classes at work behind the request object) brings all the validation checks into one location rather than, possibly, dispersed throughout the app wherever you access a superglobal.
    Exactly, I've said as much in the skeleton thread yes? Are we learning now...

  8. #8
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    naperville
    Posts
    189
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff - you talk about the CLI a lot, and I know you've done testing with it, but I've never actually came onto an occasiaon where I had to use it. What kind of scripts are you using CLI with, if you dont mind me asking?

    b1ind - yeah, thats what I would of done if I didn't use one.

    Doc - I think I got what you meant. You're coupling the data to a specific component/module/etc instead the framework as whole?

    Right now, I think the main issue for me is still "where's that data coming from?". I'm not convinced it matters, but at the same time, it worries me. I'm sure if I heavily tested that part of the application with "does it matter" in mind, I could be reassured one way or another - I could submit the var in mutliple formats, or combinations of. I think testing might be the answer to this dilemna.

    The $Request->getFoo() - does that refer to getVar, or would it be used like getPost('var') ? The getVar is an interesting idea, because then all validation would be done inside the class (I typically do it outside request, and modify the data).

  9. #9
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay,

    In the skeleton thread I said that I encapsulate the Request and Response within a RequestHandler class. McGruff had questioned this motive I think, but I get the feeling he is catching on?

    This was for a number of reasons, for example application to application, the RequestHandler is disposable. You throw it away, because within this RequestHandler is application specific logic, for example to validate an ID or other global parameter. This makes the Request and Response classes more re-usable, as they are not changed from application to application, ie

    When I do care I find $request->isPost() clearer.
    That belongs in the RequestHandler object, and not the Request object, as it's not a given cert you'll need it for every application.

    As for the other part I was talking about, if your using $GLOBALs directly via $_GET, et al then you have absolutely no way in hell of (letting to) know one behaviour from another behaviour, in how to use them $GLOBALs in a manner in which the application expects to read/write the data.

    You lose control.

    That is where Interfaces come into it I suppose, and thus... Objects. Hope this makes more sense of it all now

    But I'd like to hear what others think about this whole Request/Response topic.

  10. #10
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The $Request->getFoo() - does that refer to getVar, or would it be used like getPost('var') ? The getVar is an interesting idea, because then all validation would be done inside the class (I typically do it outside request, and modify the data).
    In the case of the Request class I posted in the 'Skeleton' thread, it is just $request->get('var') because the Request object determines whether the request was submitted as a GET or POST and gives you the correct one. This solves the potential GPC problem of using $_REQUEST. But in CLI mode it could return args (and I have done this). I think the key is a stable interface rather than a bunch of superglobals in unknown states.
    Christopher

  11. #11
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    McGruff had questioned this motive I think, but I get the feeling he is catching on?
    I am a bit fed up with the way you spam this forum with stream-of-consciousness gibberish.

    Not being very expert with php isn't a crime. It is however rather galling to see false prophets such as yourself posturing and preening. You talk the talk; you don't walk the walk.

  12. #12
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As for the other part I was talking about, if your using $GLOBALs directly via $_GET, et al then you have absolutely no way in hell of (letting to) know one behaviour from another behaviour, in how to use them $GLOBALs in a manner in which the application expects to read/write the data.

    You lose control.
    I think the key is a stable interface rather than a bunch of superglobals in unknown states.
    This is what I'm referring to, looks like there is something in those two statements huh

  13. #13
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You talk the talk; you don't walk the walk.
    By that, you mean exactly what McGruff? Sure your not an expert, neither am I, and I'll be the first to admit that.

    No shame in saying that, you come here to help others and to learn, just as I do. Just because I have a flair of personality now and again, doesn't mean to say that you can distort my character.

    Don't be so quick to knock someone down okay? Behave yourself, listen and read what I post, and you might actually learn something from me.

    Are we learning now...
    This isn't personal McGruff, it's humour. My sense of humour yes? I know it's dry and sometimes it isn't really funny, but that's just my humour. Don't read too much into it please...

  14. #14
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not many people know that McGruff and Dr Livingston are actually lovers, nor that they sit together in their flat, computers on adjacent desks, not speaking, but typing furiously to each other. It's really quite sweet if you think about it. You think it's bad here, you should read their exchanges in forums about Alsatian puppies or nouvelle cooking or .... well the fur does fly! Perhaps they should have their own thread?
    Christopher

  15. #15
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    .."foo" could have come from anywhere.
    It could come from anywhere, but it must come from somewhere. As long as you know where that somewhere is, you can shove the data in $_GET if you want to. eg, while testing you could set $_GET and friends in the setUp() function, and the script will be none the wiser.

    @arborint:

    Douglas
    Hello World

  16. #16
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Super Phil
    I'm not convinced it matters, but at the same time, it worries me.
    This probably applies in a round about way: http://headrush.typepad.com/creating...itis_vs_t.html

    With a complex interface, you have to push a lot of buttons and read the manual to even figure out that it doesn't do that. And you'll never really be sure; you'll carry the nagging uncertainty around with you until it settles in as a knot in your neck or something.
    I think most of the arguments for a simple user interface apply to a having a simple framework API/user experience: if there is a "worry" or a "not sure", then that person won't use that framework. To make it useful, from a zoomed out view it has to be simple. (I think that is why PHP is popular in the first place: the zoomed out view is very simple. You stick the <?php ?> in the HTML.)

    Douglas
    Hello World

  17. #17
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Not many people know that McGruff and Dr Livingston are actually lovers, nor that they sit together in their flat, computers on adjacent desks, not speaking, but typing furiously to each other. It's really quite sweet if you think about it. You think it's bad here, you should read their exchanges in forums about Alsatian puppies or nouvelle cooking or .... well the fur does fly! Perhaps they should have their own thread?
    Heh heh ... +rep to arborint

    Quote Originally Posted by Super Phill
    Whats your thoughts?
    I agree. I can't see the real need for a Request-object either. With regards to magic-quotes, I percieve that as a bug, which has to be patched. This could be done from a global function, since the superglobals are global anyway.

    Now, the only real argument for using a Request-object would be that you can have multiple instances at the same time. But I can't imagine a situation where that would be a requirement, since in php, the relationship between process and request is always 1:1. (unlike in java). Even during testing, you will only have one request at a time.

    Quote Originally Posted by arborint
    I find having as single $request->get('myparam') function simplifies the code. When I don't care whether it is get or post I don't have to think about it. When I do care I find $request->isPost() clearer.
    $_REQUEST ?

    Quote Originally Posted by McGruff
    A "request gateway" (there would be other classes at work behind the request object) brings all the validation checks into one location rather than, possibly, dispersed throughout the app wherever you access a superglobal.
    You would need access to the Model-domain in order to do any real validation, wouldn't you ? I honestly think that belongs to the Controller, or even the Model-layer.

  18. #18
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken

    $_REQUEST ?
    ...is not sufficient most of the time. Some vital features _REQUEST is missing are

    1) headers, inclusive http authorization
    2) mutlipart forms aka $_FILES
    3) request body aka php://input

    In other words, it would be nice to have something like
    http://java.sun.com/j2ee/sdk_1.3/tec...etRequest.html

    Especially useful seems to be session integration (getSession() and friends). Sessions are request-time entities and should be handled in request processing phase.

  19. #19
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I google'd and found this :
    http://www.ister.org/code/ister/index.xhtml

    It's yet-another-framework-for-php, but it has some real nice HttpRequest classes. It seems to be modelled over jsp ?

  20. #20
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think, there is nothing hard about writing such class. Except session support, which could be a bit tricky, most of methods will be one-liners (thanks to php that does all real job for us ).

  21. #21
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    $_REQUEST ?
    Again the problem with $_REQUEST is that based on the server's GPC settings a var could be overwritten by another var of the same name. That is why the Request determines how the page was submitted and returns only those values.
    Christopher

  22. #22
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not many people know that McGruff and Dr Livingston are actually lovers, nor that they sit together in their flat, computers on adjacent desks, not speaking, but typing furiously to each other. It's really quite sweet if you think about it. You think it's bad here, you should read their exchanges in forums about Alsatian puppies or nouvelle cooking or .... well the fur does fly! Perhaps they should have their own thread?


    Not sure what to make of that, at least you've got a sense of humour as well though

  23. #23
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by stereofrog
    I think, there is nothing hard about writing such class. Except session support, which could be a bit tricky, most of methods will be one-liners (thanks to php that does all real job for us ).
    I use a second object representing Sessions, since to me session = state, which is different than request.

  24. #24
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not sure what to make of that, at least you've got a sense of humour as well though
    I am glad you took it the right way. No harm intended. You are both good guys and contributors to the forum (who just happen to irritate each other ).
    I use a second object representing Sessions, since to me session = state, which is different than request.
    Could you show us your Session class or a cut down version ot it?

    Here is a basic version of the one I use:
    PHP Code:
    class Session {
    var 
    $started false;

    function 
    Session () {
    }
        
    function 
    start () {
        if (! 
    $this->started) {
            if (
    strstr($_SERVER['HTTP_USER_AGENT'], 'MSIE')) {
    // make sure IE caches files properly
                
    session_cache_limiter('must-revalidate');
            }

            
    session_start();
            
    $this->started true;
        }
    }
        
    function 
    getID ($name) {
        return 
    session_id();
    }
        
    function 
    setID ($id) {
        
    session_id($id);
    }
        
    function 
    getVar ($name) {
        if (
    $name) {
            return 
    $_SESSION[$name];
        } else {
            return 
    null;
        }
    }
        
    function 
    setVar ($name$value) {
        if (
    $name) {
            
    $_SESSION[$name] = $value;
        }
    }
        
    // end class Session 
    What other features do people think a Session class needs? Referer check? Set/get vars in a hierarchy (like a DataSource)? Generate an internal unique ID that can be used to check for spoofing? Regenerate the session ID?
    Christopher

  25. #25
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Not many people know that McGruff and Dr Livingston are actually lovers...
    We've kissed and made up. Apologies.


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
  •