SitePoint Sponsor

User Tag List

Page 4 of 16 FirstFirst 1234567814 ... LastLast
Results 76 to 100 of 397
  1. #76
    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 Viflux
    Is the encapsulation of HttpRequest and HttpResponse an attempt at duplicating how you would handle the situation with a Java Servlet?
    That's what it looks like to me

    "design a 'skeleton' script?" Sure! Just hold on while I reinvent Java...

    Off Topic:

    Seems like we have three options IMO:

    • Reinvent Java Servlets (or something else from Java land)
    • Reinvent Rails (which uses a request object plus a "params" hash)
    • Invent something to fit PHP


    Though I don't want to tun this into a smaller version of the 'What can a web app developer like about Java?' thread

    I've not used Java Servlets btw, so I can't speak about them
    Hello World

  2. #77
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is the encapsulation of HttpRequest and HttpResponse an attempt at duplicating how you would handle the situation with a Java Servlet?
    Nope, that isn't what I have in mind. The reasoning behind me encapsulating the HttpRequest (and HttpResponse for that matter) is to increase the re-use of the encapsulated classes.

    For example, the Request class is disposable from application to application. Take verifying and validating an ID (which determines which page to dispatch for example?) yes? This isn't constant between applications, ie It could change.

    So I leave it to the Request class to manage this change (from application to application), but the Request class does need access to HttpRequest to fetch the parameter from $_REQUEST. The Request class therefore, does not and is not concerned with where it fetches the parameter(s) from.

    I could put just about anything to the Request class it's self, provided the Interface fits I suppose (but why I'd want to do that I don't know, there is no reason to). So, the Request class facalitates how the application uses the request parameters in an indirect manner

    On the point of Java Servlets, kind of pointless to try to recreate them for PHP. Remember, PHP isn't Java

  3. #78
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A lot to respond to:
    Is the encapsulation of HttpRequest and HttpResponse an attempt at duplicating how you would handle the situation with a Java Servlet?
    Yes and no. Not really because there are differences between the problems the objects are solving between Java and PHP. Yes because it is an obvious thing to encapsulate. Certainly you don't want to implement solutions from other languages that are inappropriate for PHP. Likewise you don't want to ignore smart solutions from other languages just because they are not invented here.

    The goal here is to solve real problems in PHP. Those posting code here have run up against these problems and come to similar solutions. We are looking to see if there is a common base code that we can agree on.
    Dr. Livingston: I don't make the destinction of where the request comes from, either $_GET or $_POST, I use $_REQUEST instead.
    The problem with this is that $_REQUEST vars of the same name from different sources can overwrite each other in different order depending on the servers GPC settings. One of the goals of the Request object is to provide a level playing field between different PHP installations with regards to GPC and magic quotes, etc.
    kyberfabrikken: sometimes you actually might want to distinguish between GET and POST within the same request.
    True, we could provide getPost() and getGet() (and cookies?) fuctions in the Request if people thought them necessary. Any votes for those? However, 99% of the time you want to use the vars from the mode in which the page was submitted (get or post).
    kyberfabrikken: If we should have a Request class, I must insist to also have a Response-class.
    I think that's fine. Please propose a Response class and we can incorporate it to set headers, cause a redirect, etc.
    I think you're right. I used InputController because I can't figure out exactly where the difference is between FrontController and ApplicationController, so I don't really bother to distinguish. To me they're just InputControllers. Perhaps they are even just Controllers ? It's about the context anyway, since you could easily have two bootstrap-scripts, each looking like the above code. Would they be FrontControllers ?
    I would be good if we could base both the FrontController and ApplicationController on a base Input Controller (or just Controller). Perhaps someone can have a try at coding that.
    I think we can probably agree on how to implement things, but we will differ on which elements to include. The discussion about Request and Response isn't as much if they are appropriate (I agree that Request has uses, even though it may not seem that way from my posts). The question is if it's needed in very simple applications ? I think not, and you would probably agree?
    I would like to work toward agreeing on what elements to include. I am willing to be flexible. I think our rule should be to include a thing unless there is active resistance against it for design or complexity reasons. For example, I think there is technical resistance to combining the Request and Response classes, but including a Request class seems to be more a choice some would not make.
    The same thing goes for Handle (which I earlier suggested used with the RequestMapper). It's really useful, and I wouldn't leave home without it, but for a minimal setup it's overhead, since it essentially trades simplicity for efficiency.
    I think we should include a Handle class because it proviede Lazy Include and simplifies what the Dispatcher does by separating out the include/instantiate to a separate, testable class.
    As you see, I use ServerPages (aka DispatcherView) as the default view. So that would be your 'page'. Action is a Command - it performs some sort of update to the Model and redirects to a view (ServerPage).
    I think we should decide whether we want to support both dispatching actions and simply including PHP pages. What do people think? Is providing dispatcher that is a PHP page includer an addition that might just confuse? Or is it a good first stepping stone for someone like cadmiumgreen to get their code working and then add Actions?

    kyberfabrikken: I need to look at you Action and View code to give a response to it.

    Also, If you look at the code I posted, the main thing I changed was to combine you Input Controller and RequestMapper_MapperChain because I think this produces a real contoller. A controller doesn't just dispatch. It needs to provide some real control by combining several functions together.

    I keep mentioning an Application Controller. I think it is easier to understand an Application Controller if you think of it as the common control parts of all your "application" scripts pulled out and put in a base class. Each "application" script then extends the base class. This has the powerful effect of simplifying what each "application" script contains so that it is mostly the code specific to that task with most of the housekeeping code separated out.
    Christopher

  4. #79
    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
    I don't make the destinction of where the request comes from, either $_GET or $_POST, I use $_REQUEST instead.
    There are important differences between the three and you really cannot treat them in the same way.

    A missing key in $_COOKIE is no cause for alarm: it might not have been set yet or the user might have cleared out his cookie store. How that affects the application flow depends on what the cookie is used for. You might, for example, require to show a login page.

    A missing key in $_POST could simply mean that a user forgot to fill in a form field. The form may need to be redisplayed.

    A missing key in $_GET would probably mean query string tampering, assuming there are no errors in the links you create. Also, sometimes you can have optional $_GET keys. You will know that in advance of course and can decide if the request syntax is correct or not.

    Invalid values in $_COOKIE or $_GET indicate tampering, again assuming there are no application errors. Invalid values in $_POST may simply mean the user filled in the form incorrectly.

    So, missing keys or invalid values mean different things in the different GPC superglobals and will require different responses.

  5. #80
    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
    I think we should decide whether we want to support both dispatching actions and simply including PHP pages. What do people think? Is providing dispatcher that is a PHP page includer an addition that might just confuse? Or is it a good first stepping stone for someone like cadmiumgreen to get their code working and then add Actions?
    It is indeed an important decission. I think it's important to leave it to the user to decide witch view-strategy to use. The dispatcherview is the simplest solution, and I think it's especially suitable for lesser experienced programmers.

  6. #81
    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 Viflux
    Re-read what you quoted
    Really...

    Silly me.

  7. #82
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, here's my hacking togetherness. I've taken out lots of return NULLs because that's what happens anyway. Added kyberfabrikken's ActionFactory too. I've also added the disable_magicquotes code from the PHP site.

    It also shows an advantage of using a request class: you can add the silly isset($_GET['something']) test globally

    PHP Code:
    /* Disable Magic Quotes */
    /* http://www.php.net/magicquotes.disabling */
    if (get_magic_quotes_gpc()) {
      
       function 
    stripslashes_deep($value) {
           
    $value is_array($value) ?
                       
    array_map('stripslashes_deep'$value) :
                       
    stripslashes($value);
           return 
    $value;
       }

       
    $_GET array_map('stripslashes_deep'$_GET);
       
    $_POST array_map('stripslashes_deep'$_POST);
       
    $_COOKIE array_map('stripslashes_deep'$_COOKIE);
       
    $_REQUEST array_map('stripslashes_deep'$_REQUEST);
       
    }

    class 
    Request
    {
        var 
    $_path_info;
            
        function 
    Request() {
            
    $this->_path_info $_SERVER['PATH_INFO'];
        }
        
        function 
    get($name) {
            return isset(
    $_REQUEST[$name]) ? $_REQUEST[$name] : '';
        }
        
        function 
    set($name$value) {
            if (
    $name$_REQUEST[$name] = $value;
        }
        
    }

    class 
    Dispatcher_ServerPage
    {
        var 
    $_directory './';
        var 
    $_file_name;

        function 
    Dispatcher_ServerPage($file_name) {
            
    $this->_file_name $file_name;
        }
        
        function 
    execute() {
            @include(
    $this->_directory $this->_file_name);
        }
    }

    class 
    RequestMapper_Default
    {
        var 
    $_default;
        
        function 
    RequestMapper_Default($default) {
            
    $this->_default $default;
        }
        
        function & 
    map(&$request) {
            return new 
    Dispatcher_ServerPage($this->_default);
        }
    }

    class 
    RequestMapper_ServerPage
    {
        function & 
    map(&$request) {
            if (
    $page $request->get('page')) {
                return new 
    Dispatcher_ServerPage($page);
            }
        }
    }

    class 
    RequestMapper_Action
    {
        var 
    $_factory;
        
        function 
    RequestMapper_Action(&$factory) {
          
    $this->_factory =& $factory;
        }
        
        function & 
    map(&$request) {
            if (
    $action $request->get('action')) {
                if (
    preg_match("/^(\w*)$/"$action)) {
                    return 
    $this->_factory->create($action);
                } else {
                    
    trigger_error('The "'.$action.'" action does not exist.'E_USER_WARNING);
                }
            }
        }
    }

    class 
    ActionFactory
    {
        function & 
    create($action) {
            
    $class_name 'Action_'.$action;
            if (!
    class_exists($class_name)) {
                require_once(
    'Actions/'.$action.'.php');
            }
            return new 
    $class_name;
        }
    }

    class 
    FrontController
    {
        var 
    $_mappers = array();

        function 
    append(&$mapper) {
            
    $this->_mappers[] =& $mapper;
        }

        function 
    execute(&$request) {
            foreach (
    $this->_mappers as $mapper) {
                
    $dispatcher =& $mapper->map($request);
                if (
    is_a($dispatcher'Dispatcher_ServerPage')) {
                    return 
    $dispatcher->execute($request);
                }
            }
        }
    }


    $chain =& new FrontController();

    $chain->append(new RequestMapper_Action(new ActionFactory()));
    $chain->append(new RequestMapper_ServerPage());
    $chain->append(new RequestMapper_Default('default.php'));

    $chain->execute(new Request()); 
    I don't think I've broken anything... anyone care to write some unit tests? I see how it works, but I'm not feeling why it is all needed yet. So documenting tests would be great

    Douglas
    Hello World

  8. #83
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is indeed an important decission. I think it's important to leave it to the user to decide witch view-strategy to use. The dispatcherview is the simplest solution, and I think it's especially suitable for lesser experienced programmers.
    Ok. I can see that of DispatcherView would be useful. It would be good if the Front Controller can be used:

    - with their current PHP scripts using include (for cadmiumgreen)
    - with Actions that are simply Transaction Scripts
    - Actions that are full Application Controllers

    I think the general goal of providing choices should prevail. My complaint about many framework's controllers is that they are become too specific.

    Questions:

    Do you want proceed using the combined Input Controller and RequestMapper_MapperChain in the code I posted? (We can change its name if you really hate "FrontController") I think it is more of a controller and it has the Request integrated and is debugged. I'd be interested in your comments on the possible directions we could go here. Eventually having a base Input Controller might be a good direction to go.

    Should we add a Handle class and integrate it into the dispatcher?

    How do we handle errors, such as the include file does not exist? At what level are these problems handled?
    Christopher

  9. #84
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is an interesting read about the CoR: http://www.research.umbc.edu/~tarr/d.../Chain-2pp.pdf (it is also an example of how NOT to write a PowerPoint presentation)

    It says how Java 1.0 used CoR for the GUI, but that it was slow an inefficient. It then goes on to say how they moved to the Observer pattern to gain efficiency in Java 1.1.

    Douglas
    Hello World

  10. #85
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    They (apparently) had additional issues with CoR ie problems with allowing non-GUI objects to handle events.

    CoR is, I think, good as long as there aren't a large number of objects in the chain. Objects can be lazy-loaded into the chain as needed. With Observer, I think all the observers would have to be instantiated even if not required.

    My memory of the WACT Handle class is failing me now - perhaps it deals with this very issue?

    I don't think I'd use a CoR for the FrontController role: WACT again provides an example of directly instantiating something based on request vars. On the other hand, for an application controller, I think it's a good fit with (more or less) one handler per possible page which can be created in response to a specific http request. A FrontController could set up a particular CoR handler configuration.

  11. #86
    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
    My memory of the WACT Handle class is failing me now - perhaps it deals with this very issue?
    http://cvs.sourceforge.net/viewcvs.p...hp?view=markup

    ?

    I still like the MVC ideas I posted here: http://www.sitepoint.com/forums/showthread.php?t=252847

    Looking at it now, it needs better support for redirection (with more encapsulation of the actions) but basically I think it is good.

    Douglas
    Hello World

  12. #87
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  13. #88
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is a basic Handle class that I use. It is more generic than the WACT one for example as it is more like lastcraft's Invoker class. If you think it is useful, lets integrate it into the controllers. Feel free to change or add to it.
    PHP Code:
    class ObjectHandle {
    var 
    $file '';
    var 
    $class '';
    var 
    $method '';
    var 
    $args null;
    var 
    $instance null;

    function 
    ObjectHandle (/* $file, $class, $method, $args ... */) {
        if (
    func_num_args()) {
            
    $this->args =& func_get_args();
            
    $this->file array_shift($this->args);
            
    $this->class array_shift($this->args);
            
    $this->method array_shift($this->args);
        }
    }

    function & 
    construct (/* $args ... */) {
        if (
    $this->class) {
            if (!
    class_exists($this->class) && !$this->instance) {
                @include_once(
    $this->file);
            }

            if (
    class_exists($this->class)) {
                if (!
    $this->instance) {
                    
    $arglist = array();
                    if (
    func_num_args()) {
                        
    $args =& func_get_args();
                        
    $n count($args);
                        for (
    $i=0$i<$n; ++$i) {
                            
    $arglist[$i] = "\$args[$i]";
                        }
                    }
                    eval(
    "\$this->instance =& new {$this->class}(" implode(', '$arglist) . ');');
                }
                return 
    $this->instance;
            }
        }
    }

    function & 
    resolve(/* $object, $args ... */) {
        if (
    func_num_args()) {
            
    $args =& func_get_args();
            
    $object array_shift($args);
        } else {
            return 
    false;
        }
        if (
    get_class($object) == 'ObjectHandle') {
            return 
    $object->construct($args);
        } else {
            return 
    $object;
        }
    }

    // end class ObjectHandle 
    Christopher

  14. #89
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think I'd use a CoR for the FrontController role
    Perhaps a straight loop like an Intercepting Filter would be more appropriate?
    I still like the MVC ideas I posted here: http://www.sitepoint.com/forums/showthread.php?t=252847
    I see no reason why we can't support both types of Actions. What needs are there to dispatch both types?
    Christopher

  15. #90
    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
    Here is a basic Handle class that I use. It is more generic than the WACT one for example as it is more like lastcraft's Invoker class.
    Yeah, the class from WACT is lefthand work (Appoligies to the 10% out there). Yours looks fine, so let's stick with that. It's probably a good idea to name it ObjectHandle rather than Handle, since the latter could mean many things.

    Quote Originally Posted by DougBTX
    I still like the MVC ideas I posted here: http://www.sitepoint.com/forums/showthread.php?t=252847
    That strategy is basically to map a request to both a class and a function, right ? Using the class as the namespace for the functions.
    That could be done by something like this :
    PHP Code:
    class RequestMapper_ActionPackMapper extends RequestMapper
    {
        function & 
    mapRequest() {
            if (isset(
    $_GET['controller'])) {
                
    $route = Array(
                    
    'controller' => $_GET['controller'],
                    
    'action' => isset($_GET['action']) ? $_GET['action'] : 'default'
                
    );
                return new 
    Dispatcher_ActionPack($route);
            }
        }
    }
    class 
    Dispatcher_ActionPack extends Dispatcher
    {
        var 
    $route=Array();
        function 
    Dispatcher_ActionPack($route) {
            
    $this->route $route;
        }
        function 
    execute() {
            
    $controller $this->route['controller'];
            
    $action $this->route['action'];
            if (!
    class_exists($controller)) {
                require_once(
    $controller.'.php');
            }
            eval(
    "$controller::pre_filters();"); 
            eval(
    "$controller::act_$action();"); 
            eval(
    "$controller::post_filters();");
        }

    Quote Originally Posted by DougBTX
    OK, here's my hacking togetherness. I've taken out lots of return NULLs because that's what happens anyway.
    Yeah, that's a bad habit I picked up doing some C-programming recently.
    Quote Originally Posted by arborint
    Please propose a Response class and we can incorporate it to set headers, cause a redirect, etc.
    This is (almost) direct copy&paste from my working setup :
    PHP Code:
    class Response
    {
        var 
    $headers=Array();
        var 
    $content="";
        var 
    $redirect=NULL;

        function 
    setHeader($key$value=NULL) {
            
    $this->headers[$key] = $value;
        }

        function 
    getHeaders() {
            return 
    $this->headers;
        }

        function 
    setRedirect($url) {
            
    $this->redirect $url;
        }

        function 
    getRedirect() {
            return 
    $this->redirect;
        }

        function 
    setContent($content) {
            if (!
    is_null($this->redirect)) {
                
    trigger_error("The response is set to redirect - content will not be preserved"E_USER_NOTICE);
            }
            
    $this->content $content;
        }

        function 
    getContent() {
            return 
    $this->content;
        }

        
    /**
          * @returns    void
          */
        
    function execute() {
            if (!
    is_null($this->redirect)) {
                
    header("Location: ".$this->redirect);
                exit;
            }
            foreach (
    $this->headers as $key => $value) {
                if (
    is_null($value)) {
                    
    header($key);
                } else {
                    
    // normalize headers ... not really needed
                    
    for ($tmp explode("-"$key), $i=0$l=count($tmp);$i<$l;$i++) {
                        
    $tmp[$i] = ucfirst($tmp[$i]);
                    }
                    
    header(implode("-"$tmp).": ".$value);
                }
            }
            echo 
    $this->content;
        }

    Quote Originally Posted by arborint
    I think we should decide whether we want to support both dispatching actions and simply including PHP pages.
    I'm confused? That's exactly what Dispatcher_ServerPage does.
    Edit:

    Or did you mean to discus whether we should dispose of it ?


    Quote Originally Posted by arborint
    How do we handle errors, such as the include file does not exist? At what level are these problems handled?
    I think we better leave that out of scope. trigger_error() works fine to halt execution, and if people want a more subtle error-handler, they can probe into the native error-handler of php.
    Last edited by kyberfabrikken; Jun 13, 2005 at 05:09. Reason: Captain Proton makes a point

  16. #91
    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
    Do you want proceed using the combined Input Controller and RequestMapper_MapperChain in the code I posted?
    I actually started my code out that way, but I like it better to have the MapperChain inherit from RequestMapper. It's probably mostly an aestethic choice to make though. The only real argument I can come up with is, that by aggregating the chain, you make it possible to do without it.
    For a very simple setup, you could just add a single mapper, instead of adding the chain in. And in relation to our discussion on whether to add in support for Handle; This behaviour would be encapsuled within the chain, so if the user didn't want to use handles, or wanted a different implementation, it would be possible to write a substitute chain, rather than a seperate FrontController.

    About the name ... I don't want to be labeled a fanatic, so if there is a majority for calling it FrontController, so be it.

  17. #92
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's probably a good idea to name it ObjectHandle rather than Handle, since the latter could mean many things.
    You're kidding, right? In what way is an ObjectHandle less generic than a Handle, considering that 'objects' in the dictionary sense can be anything?

  18. #93
    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 Captain Proton
    You're kidding, right? In what way is an ObjectHandle less generic than a Handle, considering that 'objects' in the dictionary sense can be anything?
    I was thinking opposed to a lazyloaded record used in ORM. But I didn't really think it through, because you're ofcourse right - ObjectHandler isn't any better than Handle.

  19. #94
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I actually started my code out that way, but I like it better to have the MapperChain inherit from RequestMapper. It's probably mostly an aestethic choice to make though. The only real argument I can come up with is, that by aggregating the chain, you make it possible to do without it.
    For a very simple setup, you could just add a single mapper, instead of adding the chain in.
    I see your point, but I think that consistency would be better. If someone only has a simple single mapper then the code would still look the same as more complex configurations and adding mappers would just be adding a line. What do others think about this? Two functions or one?
    And in relation to our discussion on whether to add in support for Handle; This behaviour would be encapsuled within the chain, so if the user didn't want to use handles, or wanted a different implementation, it would be possible to write a substitute chain, rather than a seperate FrontController.
    I agree completely. I think the controllers should use/support handles internally, but if you don't want to use them they are transparent.
    You're kidding, right? In what way is an ObjectHandle less generic than a Handle, considering that 'objects' in the dictionary sense can be anything?
    I think a handle is a very generic concept. For example, FileHandles are pretty common things. Whenever I see "handle" by itself, I want to know "handle to what?" That's why I named mine ObjectHandle. If most prefer "Handle" I have no problem changing it though, as it's just naming.
    Christopher

  20. #95
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    kyberfabrikken, Captain Proton, DougBTX, et al, I feel like we have a lot of good code and are much closer to actually having something workable than in previous threads. It just needs to get massaged together. Any proposals for how to get this done and how to make any of the dangling design decisions still left?
    Christopher

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

    On the matter of a mapper, the road I'm taken (in my specific case anyways, your needs may vary) is that I create a dispatch service based on a factory.

    This factory (lets name it factory_xyz), will return the service encapsulated within another factory (lets name it factory_abc). Now, to map a request to a given action, I need to query the database (for example, could just as well be an xml file, as there are various services) to locate the configuration file, for that request.

    It's this configuration file (used by factory_abc) which decides on the composite structure to use, which in turn is how I construct the final page (but that's complex so I'll not go there).

    So, how does the factory_abc know what to query? Based on that there are various services, such as database, xml, web service, etc? What I am thinking, is that I could pass into the factory_abc, a servicable object which'd already have the information set up, for the service to query. Ie,

    PHP Code:
    // ... client script
    $servicable = new SqlQueryGetByIdServicable;
    $servicable -> id $this -> handler -> getId();
    $walker $this -> factory -> compose$servicable );
    // ... 
    PHP Code:
    class SqlQueryGetByIdServicable implements IServicable {
    public 
    $id;

    public function 
    __construct() {}

    public function 
    fetch() {
    // could just as well be an xpath expression...
    return 'select * from commands where id = '.$this -> id;
    }
    }
    // only one fetch() (responsibility) per servicable object
    // increases flexibility, and also you then don't need to modify a service,
    // to add more servicables (responsibility) later :) 
    Another benifit of the servicable object, is that regardless of what service I'm using, the factory_abc still knows what to do with it, as the servicable object adheres to an interface, as apposed to just passing an array (of arguments) into factory_abc).

    In the end, factory_abc returns an object I can use (construct the page). This is particularly convienent, as the requested action may be invalid, so it's just the object that you throw away.

    I like this approach, as there is next to no duplication of script. Going by some of the examples posted over the last day or so, on the mappers, there is some duplication between each mapper.

    If someone only has a simple single mapper then the code would still look the same as more complex configurations and adding mappers would just be adding a line. What do others think about this?
    You are talking one or more mappers, whereas I have just the one (service), but I'd be interested in reading what others think, as well
    Last edited by Dr Livingston; Jun 13, 2005 at 12:23. Reason: clarity and add an example ;)

  22. #97
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ?

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

    UML or diagram

    Would someone mind creating a diagram of how this system is going to work along with the terminology?

    - matt

    EDIT:
    Actually just a post with the terms/definitions (Application Controller, Mapper etc.) and what their roles are?

  24. #99
    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 mwmitchell
    Would someone mind creating a diagram of how this system is going to work along with the terminology?
    As to terminology, I assume that we use Fowler, PoEAA.
    I'll try to assemble the code within this thread, and throw it up at cvs in the sourceforgeproject, that arborint created recently. When it's done, I'll post back here with a class-diagram aswell.

    DR Livingston: I've read your post three times now, and I still can't figure out what on earth you're talking about ?

  25. #100
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    - matt

    EDIT:
    Actually just a post with the terms/definitions (Application Controller, Mapper etc.) and what their roles are?
    Hi Matt,

    This catalog has most of the definitions and basic UML diagrams.

    HTH
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.


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
  •