SitePoint Sponsor

User Tag List

Page 10 of 16 FirstFirst ... 67891011121314 ... LastLast
Results 226 to 250 of 397
  1. #226
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I would want to rename Mapper to RequestMapper. Mapper isn't very discriptive, it's a general pattern.
    True.
    RequestMapper shouldn't extend from Controller
    Also true. A lapse out of not thinking at all.
    The RequestMapper also doesn't need the Response object.
    I think it could. Say, you use .htaccess to redirect 404 errors to the script in order to support fancy urls; there's a 404 error that needs to be countered. I would definitely use the RequestMapper to set a 200 OK header in the Response, as seen in the code.
    I like that you have introduced an abstract Controller class. Although I don't see why you have the event_initialize() method ? Descendants could just use their constructor for this.
    Not necessarily they could; it's possible for the constructor to be reserved for other purposes. I find it nice and clean for there to be a single initiator method for things like filters and models. However, Controller perhaps isn't the best place to put this. Moved to Dispatcher.
    The interface Filter should probably have one method for pre and one for post processing. If not, a filter won't be able to execute at both places.
    Huh? How come it won't? It's just a matter of where in the code you actually execute the filter. Added an addWrapFilter() method just to demonstrate this.
    The execute() method of Dispatcher relies on it's descendants to call runPreFilters() & runPostFilters(). This seems awkward.
    After contradicting myself and thinking through only after posting for around twenty times, I must say I agree with on your solution fully. The execute() was indeed meant immutable.

    Skeleton 1.3 included to reflect these changes. Check to see if we're talking what I'm thinking we're talking. I have to admit this is a bit confusing, designing to fit numerous layouts at once. Do we really want the actions and dispatchers both extending the dispatcher?
    Attached Files Attached Files
    Last edited by Ezku; Jun 21, 2005 at 15:42.

  2. #227
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's time for a new reply after all those edits.

    I decided the abstract Dispatcher was of no use and - to my opinion - managed to rationalize the design a bit. FC no more extends Controller but FilterChain, and Dispatcher became the Controller, from which Actions and Dispatchers extend. This way the naming actually makes sense.

    I find Request and Response to be the fuzziest parts of the implementation. What do we want them to do? Where does Session and Cookie handling go? How do you use Response with a View object? Perhaps some of these questions are ones that need not be answered by our skeleton, though.
    Attached Files Attached Files
    Last edited by Ezku; Jun 21, 2005 at 17:03.

  3. #228
    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 Ezku
    Huh? How come it won't? It's just a matter of where in the code you actually execute the filter.
    Yes, sorry - I weren't making myself very clear. Say I want to make a filter, which times the executiontime of the dispatcher. So in the pre-phase it would store the time, and in the post-phase, it would append the difference to the content. How would the filter know if it was running on pre or post ?
    I don't know - it may be an exotic problem, but I think it may be a sign of a weakness in the design?

    I'll have a look at the posted code in the morning.

  4. #229
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Yes, sorry - I weren't making myself very clear. Say I want to make a filter, which times the executiontime of the dispatcher. So in the pre-phase it would store the time, and in the post-phase, it would append the difference to the content. How would the filter know if it was running on pre or post ?
    I don't know - it may be an exotic problem, but I think it may be a sign of a weakness in the design?

    I'll have a look at the posted code in the morning.
    Why not have the filters have access to the chain:

    PHP Code:
    function execute(){
        
    $time time();
        
    $this->next();
        
    $total time() - $time;

    EDIT: I mean the filters have access to the chain.

  5. #230
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Say I want to make a filter, which times the executiontime of the dispatcher. So in the pre-phase it would store the time, and in the post-phase, it would append the difference to the content. How would the filter know if it was running on pre or post ?
    This is perfectly doable, as you can see.
    PHP Code:
    class TimerFilter implements Filter
    {
       protected 
    $time NULL;
       public function 
    execute(Request $requestResponse $response)
       {
          if(!isset(
    $this->time))
             
    $this->time microtime(true);
          else
          {
             
    $content $response->getContent()."\r\n<!-- Execution time: ".(microtime(true)-$this->time)." microseconds -->";
             
    $response->setContent($content);
          }
       }
    }

    class 
    ActionDispatcher extends Controller
    {
       (...)
       public function 
    event_initialize()
       {
          (...)
          
    // After prefilters and before postfilters to have it time only the dispatcher execution
          
    $this->addWrapFilter(new TimerFilter);
          (...)
       }


  6. #231
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    This is perfectly doable, as you can see.
    It may be doable, but I don't think it's ideal. Having two methods called isn't neccesary though, it could just be a parameter in the exec call.

    Another thing to think about would be to maybe execute the chain of either pre or post filters backwards... why? because that way you can truly wrap filters around filters. The question would be, should filters be added from the outside in, or from the inside out?

  7. #232
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    I was thinking of actions being able to call sub-actions, but somehow it doesn't seem to fit in our current design. Composite views are a very important point in an MVC design, so I'd be glad to hear good ideas here.
    I haven't completely thought this through yet, but here's an idea; instead of having the dispatcher return a single object, have it return a tree. The root node would load a master template into the response, and would then call each of it's children in turn, which would call their children etc..., all of which would modify the response, completing the composite view.

    Looking at the code now has given me another idea. The front controller and the controller are very similar; how about making them the same class, simply a controller that can contain other controllers? The main difference between the two is the front controller's mapper, but by combining the classes we could actually have any type of controller have a mapper, which could be a way of building composite views as well.

  8. #233
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been on vacation and have missed most of the Rails injection by Ezku. And honestly I have looked at the code a couple of times and what I see is that it has gone full circle back to where kyberfabrikken and I were 20 posts back but with things hard coded to loose the generic capabilities.

    An example are pre and post filter chains. There is really no need for multiple filter chains to manage what in reality are a couple (at most) objects in the chain. We only added the FilterChain above the FrontController because it can be handy in large sites that are centralizing other logic. There is no need for the controller to add some pre/post processing order because you just add them in the order you want them. I have yet to see anyone show a configuration that uses pre/post chains that couldn't be done with a single chain. It is extra code for nothing.

    This leads me to kyberfabrikken's concern about mixing "filters" and "controllers" in the same chain. My response to that is:

    1) We know that "filter" and "controller" are not very descriptive names for the objects that will actually be in this chain. The Front Controller is just barely a controller and most of the "filters" don't filter in the traditional sense but remap, redirect, forward, etc.

    2) They are all objects that are run with $object->execute($request, $response) so I really don't care what they do, they are all the same thing to the Filter Chain.

    I'm not sure what to make of central generic code that has turned into this:
    PHP Code:
    class ActionDispatcher extends Controller
    {
        protected function 
    run(Request $requestResponse $response)
        {
            
    $action = new KilroyAction;
            
    $action->execute($request$response);
        }

    I think the Rails discussion confused the Front Controller / Application Controller separation by trying to push Application Controller functionality into the Front Controller where it does not belong.

    Re Rails: to implement a Rails type routing using our generic skeleton you would really want to write a mapper that parsed PATH_INFO and wrote the values into the request for the Application Controller to use. That can be done in a generic way by adding the routing information for each mapping as data (yes there is even a place for it) for the mapper to use to parse PATH_INFO. But I have to agree with kyberfabrikken's choice to drop all other mappers (actually mine! ) to keep focus on the controllers.

    kyberfabrikken can we find our way back from here? Going back before the CoR Filter Chain fork, my 2.4 just wrappered the Front Controller with an optional Filter Chain that you could use if you needed it or just use the FrontController alone. Though my Filter Chain code may be clunky, I think that is the general direction we want to go.
    Christopher

  9. #234
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    Finland
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is what I have been using for filtering in my own MVC-implementation.

    PHP Code:
    <?php
    class JMVC_FilterManager{
        
        private 
    $filters = array();
        private static 
    $req;
        private static 
    $res;
        
        function 
    __construct($controller){
            
    $this->controller $controller;    
            
    self::$res Request::getInstance();
            
    self::$req Response::getInstance();

        }
        
        function 
    addFilter($f){
            
    $this->filters[] = $f;
        }
        
        function 
    process(){
            
    reset($this->filters)->run($thisself::$reqself::$res);    
        }
        
        function 
    processNext(){
            if (
    $filter next($this->filters)){
                
    $filter->run($thisself::$reqself::$res);    
            }else{
                
    $this->controller->execute();    
            }
        }
        
    }
    abstract class 
    JMVC_InterceptingFilter{
        
        abstract function 
    preProcess(Request $reqResponse $res);
        abstract function 
    postProcess(Request $reqResponse $res);    
        
        public function 
    run(JMVC_FilterManager $filterChain$req$res){
            
    $this->preProcess($req$res);
            
    $filterChain->processNext();
            
    $this->postProcess($req$res);    
        }
    }
    ?>
    simple example
    PHP Code:
    class TimingFilter extends JMVC_InterceptingFilter{
        private 
    $time;
        
        function 
    preProcess($req$res){
            
    $this->time microtime(1);    
        }
        
        function 
    postProcess($req$res){
            echo 
    microtime(1) - $this->time;
        }    
    }

    $fm = new FilterManager($someController);
    $fm->addFilter(new TimingFilter());
    $fm->process(); 
    What do you think?

  10. #235
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Again, for the "front" Filter Chain I don't see the practical difference between the CoR style of JaskaS above and the code below using a single, straight Filter Chain which has less and simpler code:
    PHP Code:
    class TimingFilter {
        private 
    $time 0;
        
        function 
    execute($req$res){
            if (
    $this->time) {
                echo 
    microtime(1) - $this->time;
            }
            
    $this->time microtime(1);
        }    
    }

    $f = new FilterChain($req$res);
    $timer = new TimingFilter();
    $f->addFilter($timer);
    $f->addFilter(new FrontController());
    $f->addFilter($timer);
    $f->process(); 
    Or for that matter:
    PHP Code:
    $f = new FilterChain($req$res);
    $timer = new TimingFilter();
    $f->addFilter($timer);
    $f->addFilter(new SomePreFilter());
    $f->addFilter($timer);
    $f->addFilter(new FrontController());
    $f->addFilter($timer);
    $f->addFilter(new SomePostFilter());
    $f->addFilter($timer);
    $f->process(); 
    Note that index.php itself is the Filter Manager.
    Christopher

  11. #236
    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've been on vacation and have missed most of the Rails injection by Ezku. And honestly I have looked at the code a couple of times and what I see is that it has gone full circle back to where kyberfabrikken and I were 20 posts back but with things hard coded to loose the generic capabilities.
    (...)
    kyberfabrikken can we find our way back from here? Going back before the CoR Filter Chain fork, my 2.4 just wrappered the Front Controller with an optional Filter Chain that you could use if you needed it or just use the FrontController alone. Though my Filter Chain code may be clunky, I think that is the general direction we want to go.
    I think you're more or less right. The only thing we have added since 2.4 is a FilterChain, and at the same time we managed to bloat the implementation big time. I also agree on the putting-ApplicationController-into-the-FrontController-where-it-does-not-belong thing. Maybe we should leave the filters as you have suggested, and have a closer look at the ApplicationController ?

    I have attached an update of the code from 2.4. The only real difference is that I have added a FilterChain class, which one may use around the FrontController if needed. It's optional though, which is a big plus, I think.

    Any suggestions as to how to approach the ApplicationController ?
    CompositeViews has been mentioned already, but I think that's another ballgame really. It has to do with the rendering, and as such is more closely tied to the View. I do have some ideas in this field, but I think we better wait a bit with that.
    Attached Files Attached Files

  12. #237
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Arborint's response surprised me a bit. I think there's some confusion on what my code sample was an what it wasn't supposed to be. He makes some valid points, though, but I had to put my brains to work to understand what he actually meant.
    Quote Originally Posted by kyberfabrikken
    I have attached an update of the code from 2.4. The only real difference is that I have added a FilterChain class, which one may use around the FrontController if needed. It's optional though, which is a big plus, I think.
    Seems like I have the exact same result, but in PHP5. I decided to call mine a HandlerChain instead, since there are no actual filters. By using this class the RequestMapper can return a tree (or forest) of executable objects, it's only up to the designer to create one.
    CompositeViews has been mentioned already, but I think that's another ballgame really. It has to do with the rendering, and as such is more closely tied to the View.
    Well, it's not just about rendering, the data has to be collected as well - ie. composite views require us to perform more than one action.

    We seem to have reached common ground on part of the FC and it's indeed time to take a look at the ApplicationController.
    Attached Files Attached Files
    Last edited by Ezku; Jun 22, 2005 at 06:48.

  13. #238
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    CompositeViews has been mentioned already, but I think that's another ballgame really. It has to do with the rendering, and as such is more closely tied to the View.
    The Composite View offers a lot more flexiblility in what you can do in regards to rendering a web page, though there is added complexity as well. It's not simple a case of recursing the structure as some might think, so be careful

    But as you've suggested Kyber, the script thus far, is not really ready for a Composite implementation at the moment...

  14. #239
    SitePoint Enthusiast NotThatBright's Avatar
    Join Date
    Sep 2004
    Location
    @define(State_of_Chaos, 'NY');
    Posts
    62
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I just wanted to say this entire thread has been fantastic and would like to thank all the participants. Keep up the great work, I am learning tons as this takes shape!
    _______________________________________________________________
    Casino and Poker Blogs and Articles - Web Design and Programming Services

  15. #240
    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 Ezku
    I decided to call mine a HandlerChain instead, since there are no actual filters.
    HandlerChain is a better word, I agree. The parts of the chain should implement a IHandler interface. Curiously the interface for IHandler is the samme as IDispatcher, which by the way makes a lot of sense - especially if there is going to be a double disptach (RoR). If we combine the two interfaces to one, the FrontController returns a IHandler (rather than a IDispatcher), which may in fact be another instance of FrontController. (but with another mapper). Anyone following me on that ?
    Besides the advantage of reducing the number of interfaces from 3 to 2, it has the added benifit of making the RoR-style mapping look ridiculous .

    @Dr Livingston
    I think we're on the same page there. CompositeViews should probably be left out of this thread. We could start another workshop-thread at some time, about that topic. But let's get the FrontController settled first.

  16. #241
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For the composite views... this seems like something that best handled by a dispatch type view. Creating a handler tree seems pretty difficult for a "push" style template engine. The controllers have to know all about not just the final view, but each little application within. It seems backwards to me, but of course I'm probably missing something.

    If the template engine were a "pull" type then the view itself would biuld the tree without thought. I'd rather see this get worked into some kind of simple application api like (dispatcher view / template syntax written in php for now):

    <div id="login">
    <?php $app =& Application::factory($app= 'user', $action='login'); ?>
    <?php echo $app->toString(); ?>
    </div>

    or even

    <div id="login">
    <?php Application::display('user', 'login'); ?>
    </div>

    matt

  17. #242
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The parts of the chain should implement a IHandler interface.
    Wouldn't that be the RequestProcessor interface I described earlier?

    I'd also like to know what is 'the group's definition of RequestMapper and Dispatcher. I have a feeling that some people take these two to mean the same thing (myself included).

  18. #243
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Curiously the interface for IHandler is the samme as IDispatcher, which by the way makes a lot of sense - especially if there is going to be a double disptach (RoR). If we combine the two interfaces to one, the FrontController returns a IHandler (rather than a IDispatcher), which may in fact be another instance of FrontController. (but with another mapper).
    Out of a better word for it, I just called these two combined IExecutable. That's what they do, don't they. :) Well, I suppose I'll rename it to IHandler, that makes more sense. (By FrontController you probably meant RequestMapper? The FC doesn't return anything, does it?)

  19. #244
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    I'd also like to know what is 'the group's definition of RequestMapper and Dispatcher. I have a feeling that some people take these two to mean the same thing (myself included).
    A RequestMapper is passed to the FrontController in its constructor. The RequestMapper returns what we in this context call a Dispatcher - actually it may be whatever object that implements IHandler, eg. another FrontController, a HandlerChain, an ApplicationController... This "Dispatcher" is then executed by the FrontController. Do we agree?

    Edit: Now that I look at it, this seems stupid. The object returned by RequestMapper doesn't need to be a dispatcher, no matter if its a RoRish approach or not. In a sense the RequestMapper is a dispatcher in itself - if you don't count the fact that it doesn't actually dispatch the request, it only creates an object to dispatch the request to. Are you following me? :)
    Last edited by Ezku; Jun 22, 2005 at 11:18.

  20. #245
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    I'd also like to know what is 'the group's definition of RequestMapper and Dispatcher. I have a feeling that some people take these two to mean the same thing (myself included).
    I don't think there should be confusion because Mappers and Dispatchers are very different things. They both do what the names say.

    A Mapper turns one thing into another based on an algorithm or lookup. Usually a Mapper turns a simpler thing like a name into a more complex thing like a data structure or object. The Mapper that our Front Controller uses does just that. You tell it which request parameter to use and that parameter value to create an object from based on the mapping.

    A Dispatcher runs some other code that it knows nothing about except how to run it. The thing dispatched is usually a Command -- meaning an object with a predefined method name that will be called (e.g. execute()). Our Front Controller is a Dispatcher and I think kyberfabrikken originally called it a RequestDispatcher which is a generic term. A Front Controller is one specific kind of Request Dispatcher. All of the controllers map, dispatch and manage the flow (control) in different ways.

    To the comments regarding IDispatcher,, IHandler, IExecutable, etc., I have repeatedly said that the thing dispatched is a Command. I don't mind if you want to add an interface definition for it. I just don't think that it should be required (meaning Commands run by the Front Controller do not have to inherit this interface. I would also hope that the interface would provide some more value that defining an "execute()" method. It this interface is going to be specific to the Front Controller I would call it FrontControllerCommand. If is going to be reused by other controllers then I would call it ControllerCommand.

    I am a little concerned about generic names like RequestProcessor or RequestMapper because they do not specifically describe the limited function of the things we are creating. For example a Front Controller is a kind of RequestProcessor, but so are the other Input Controllers. The same applies to RequestMapper which for the Front Controller is an ActionMapper (Struts naming) or CommandMapper (Rails naming) as it only maps one specific part of the request. It maps an action parameter to a command object. A base class for all of the controllers mappers could be called RequestMapper.

    I haven't looked at kyberfabrikken latest code. It would be great to get the Front Controller to a point where we can park it for a while and come back to it after dealing with the Application Controller. The Application Controller is a more complex beast with request processing, mapping, dispatching, probably CoR, maybe Handles, the possibly events and triggers, etc. etc. etc.
    Christopher

  21. #246
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    A RequestMapper is passed to the FrontController in its constructor. The RequestMapper returns what we in this context call a Dispatcher - actually it may be whatever object that implements IHandler, eg. another FrontController, a HandlerChain, an ApplicationController... This "Dispatcher" is then executed by the FrontController. Do we agree?

    Edit: Now that I look at it, this seems stupid. The object returned by RequestMapper doesn't need to be a dispatcher, no matter if its a RoRish approach or not. In a sense the RequestMapper is a dispatcher in itself - if you don't count the fact that it doesn't actually dispatch the request, it only creates an object to dispatch the request to. Are you following me?
    Since to object returned implements IHandler, Why not just call it a Handler?

  22. #247
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    A Dispatcher runs some other code that it knows nothing about except how to run it. The thing dispatched is usually a Command -- meaning an object with a predefined method name that will be called (e.g. execute()). Our Front Controller is a Dispatcher and I think kyberfabrikken originally called it a RequestDispatcher which is a generic term.
    Quote Originally Posted by kyberfabrikken
    Curiously the interface for IHandler is the samme as IDispatcher, which by the way makes a lot of sense - especially if there is going to be a double disptach (RoR). If we combine the two interfaces to one, the FrontController returns a IHandler (rather than a IDispatcher), which may in fact be another instance of FrontController. (but with another mapper).
    I think the only thing that really separates a FrontController from other Dispatchers is the RequestMapper that gets fed to it. Hence, especially if we're going to have multiple uses for the FC, I suggest that we rename it to Dispatcher and be done with it. Later on we could extend Dispatcher to create others, eg. FrontController, with specialized functionality if we find it's needed.

    IHandler isn't just for commands - it's for HandlerChains, FrontControllers (Dispatchers if you will) and ApplicationControllers as well, it's for all objects that the Request and Response can be passed along to. In that respect I think such a generic name fits just fine - generic just as is the interface it defines.

  23. #248
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    Since to object returned implements IHandler, Why not just call it a Handler?
    Ah, how true. So the Dispatcher is passed a RequestMapper, which returns a Handler that the Dispatcher executes. Ingenious.

  24. #249
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the only thing that really separates a FrontController from other Dispatchers is the RequestMapper that gets fed to it. Hence, especially if we're going to have multiple uses for the FC, I suggest that we rename it to Dispatcher and be done with it. Later on we could extend Dispatcher to create others, eg. FrontController, with specialized functionality if we find it's needed.
    I think that is a premature optimazation. Also from experience the Front Controller is just different enough that it does not really fit with the other controllers. The RequestMapper is pretty unique in it variation between frameworks. The other controllers use switch/CoR style mapping. Plus, as every request goes through the Front Controller, it should just do its job as simply and efficiently as possible. Finally "Dispatcher" is a generic term whereas "Front Controller" immediately communicates what it is and does.
    IHandler isn't just for commands - it's for HandlerChains, FrontControllers (Dispatchers if you will) and ApplicationControllers as well, it's for all objects that the Request and Response can be passed along to. In that respect I think such a generic name fits just fine - generic just as is the interface it defines.
    If all the controllers will be using this Command that accepts Request and Response parameters then I would call it ControllerCommand or ControllerHandler.
    Christopher

  25. #250
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A Dispatcher runs some other code that it knows nothing about except how to run it. The thing dispatched is usually a Command -- meaning an object with a predefined method name that will be called (e.g. execute()). Our Front Controller is a Dispatcher and I think kyberfabrikken originally called it a RequestDispatcher which is a generic term. A Front Controller is one specific kind of Request Dispatcher. All of the controllers map, dispatch and manage the flow (control) in different ways.
    So the RequestMapper delegates to a Dispatcher and the Dispatcher delegates to a Command? Why this extra level of indirection, when you need to go to the Command in the first place?

    Why not have something like a CommandMapper which delegates directly to a Command? In the 'To hopefully clear up some confusion' there is a perfect example of a FrontController that dispatches to a Command object. What is wrong with that?

    I believe that we have a few too many 'levels' to our design, because people have different ideas of what the concepts mean.


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
  •