SitePoint Sponsor

User Tag List

Page 6 of 16 FirstFirst ... 2345678910 ... LastLast
Results 126 to 150 of 397
  1. #126
    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
    What about using your web server as a Front Controller and mapping directly to an Application Controller?
    Something like Page Controller?

  2. #127
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I didn't know MVC put so much emphasis on splitting up the C
    Hello World

  3. #128
    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 BerislavLopac
    Something like Page Controller?
    Yes, that would be PageController IMHO.

  4. #129
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think it is time to sum things up, or atleast clarify a few things. Can we all agree on that the FC's responsibilities are:

    1. Handle (global) intercepting filters (outputbuffering, debugging, logging, timing).
    2. Extract just enough information from the request so we can determine what specific AC and action to execute.

    AC on the other should solely be dedicated to handle the dispatch process which involves:

    1. Handle (local) intercepting filters (authentication).
    2. Execute the action. The action will in turn update the Model, fetch a template and assign template variables to it, and return it to the controller.
    3. Render the template. (Another option is to apply the DispatchView pattern.)

    Comments?

  5. #130
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is a test case for the refactoring I was going on about above I don't have time to code it up at the moment, and it will need a little thought about implementation, but this is the sort of API I would be after.

    PHP Code:
    <?php

        
    require_once('simpletest/unit_tester.php');
        require_once(
    'simpletest/reporter.php');

      
    // empty classes to expand to meet the tests.
      
    class Mapper
      
    {
        function 
    connect($pattern$directions null) {}
        function 
    request($raw_request) {
          return new 
    BaseController();
        }
      }
      class 
    BaseController
      
    {
        protected 
    $params = array();
        function 
    get_params() {
          return 
    $this->params;
        }
      }
      class 
    ServerPageController extends BaseController {  }
      class 
    UserController extends BaseController {  }
      
      
      
      
    // The tests
      
    class TestOfSkeleton extends UnitTestCase
        
    {
        
        function 
    testSimpleMapping()
        {
          
    $map = new Mapper();
          
    $map->connect('/$page/', array('controller' => 'ServerPage''action' => 'show'));
          
          
    $raw_request '/about/';
          
    $controller $map->request($raw_request);
          
    $this->assertIsA($controller'ServerPageController');
          
    $this->assertEqual($controller->get_params(), array('action' => 'show''page' => 'about'));
        }

        function 
    testSimpleMappingWithoutTrainlingSlash()
        {
          
    $map = new Mapper();
          
    $map->connect('/$page/', array('controller' => 'ServerPage''action' => 'show'));
          
          
    $raw_request '/about';
          
    $controller $map->request($raw_request);
          
    $this->assertIsA($controller'ServerPageController');
          
    $this->assertEqual($controller->get_params(), array('action' => 'show''page' => 'about'));
        }
        
        function 
    testMultipleMapping()
        {
          
    $map = new Mapper();
          
    $map->connect('/$page/', array('controller' => 'ServerPage''action' => 'show'));
          
    $map->connect('/$controller/$action/$id');
          
          
    $raw_request '/about/';
          
    $controller $map->request($raw_request);
          
    $this->assertIsA($controller'ServerPageController');
          
    $this->assertEqual($controller->get_params(), array('action' => 'show''page' => 'about'));
        }
        
        function 
    testMultipleMappingAlternate()
        {
          
    $map = new Mapper();
          
    $map->connect('/$page/', array('controller' => 'ServerPage''action' => 'show'));
          
    $map->connect('/$controller/$action/$id');
          
          
    $raw_request '/user/edit/John';
          
    $controller $map->request($raw_request);
          
    $this->assertIsA($controller'UserController');
          
    $this->assertEqual($controller->get_params(), array('action' => 'edit''id' => 'John'));
        }
        
      }
      
        
    $test = &new GroupTest("MVC Controller");
        
    $test->addTestCase(new TestOfSkeleton());

        
    $reporter = new HtmlReporter();
        
    $test->run($reporter);

    ?>
    There isn't a test for a non resolved request, it could throw an error or an exception or something. Add a test for that if you like

    Whether a ServerPageController or a UserController executes an action on itself, or by creating another Action class to execute it Factory style, and so on is also not covered by these tests. A controller may have an execute() method, or it may act as soon as it is constructed, but regardless, you need that controller object to be created first, and that is what this code tests.

    Regards,
    Douglas
    Hello World

  6. #131
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Most of it is rather abstract - Could you show some example of how you would use it ?
    I have not had the time to work more on it this last couple of days, but my full intentions are to post the script, and the script in relation to the earlier interfaces I had posted, proberly along with the configuration file(s) etc.

    Just need to find the time, patience please

    Kyber, I like the UML diagram you've taken the time to put up on the forum, thanks.

    2. Extract just enough information from the request so we can determine what specific AC and action to execute.
    This is what I thought, but now I need to pass in the entire request, as there is the chance that one of those composite controllers shares information with another composite controller, so the whole composite structure (via a visitor) has access to the request. Ie A controller shares the same parameter (with another controller), or a controller looks for a one off parameter for that given request (something which is never repeated).

    So I can't just pass over known parameters in the request, based on just the one controller, as there are one or many in my case. Just thought I'd mention that.

  7. #132
    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 Overunner
    Can we all agree on that the FC's responsibilities are:

    1. Handle (global) intercepting filters (outputbuffering, debugging, logging, timing).
    2. Extract just enough information from the request so we can determine what specific AC and action to execute.
    From #2 it seems that you believe that FrontController should map the Request to two objects. Namely ApplicationController and Action.
    I don't see why. It could as easily just map to a single object. This is the case with the code I posted. The FrontController maps the Request to one object, called Dispatcher.

    Ona sidenote ; In your terminology it seems that AplicationController is synonymous with (my use of) Dispatcher ? In that case I think I finally understood what ApplicationController means. Could someone please assert this for me ?

    Quote Originally Posted by Overunner
    AC on the other should solely be dedicated to handle the dispatch process (...)
    Again - I think that I'm using the word Dispatcher when you say ApplicationController, but that we mean the same thing. Given that, I agree to the definition above.

    Quote Originally Posted by Overunner
    (...)
    which involves:

    1. Handle (local) intercepting filters (authentication).
    2. Execute the action. The action will in turn update the Model, fetch a template and assign template variables to it, and return it to the controller.
    3. Render the template. (Another option is to apply the DispatchView pattern.)
    I'd like to change that to :
    1. Handle (local) intercepting filters (such as authentication).
    2. Execute. This may result in an update of the model-layer. If the application is to be REST-full, this should result in a redirecting response. (See #3)
    3. Provide a response. This may be either a redirect or rendering of a View. The View may be a TemplateView or a ServerPage.

  8. #133
    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 have been reading up on ApplicationController.

    Quote Originally Posted by M. Fowler
    Some applications contain a significant amount of logic about the screens to use at different points, which may involve invoking certain screens at certain times in an application. This is the wizard style of interaction, where the user is led through a series of screens in a certain order. In other cases we may see screens that are only brought in under certain conditions, or choices between different screens that depend on earlier input.
    So, the FrontController selects an ApplicationController, which then selects a Dispatcher. The Dispatcher is then executed.

    I can see the reason behind this, but I think it's important to realize that a lot of requests won't need an ApplicationController. Therefore the ApplicationController should be optional. To do this, I suggest that the ApplicationController could simply be a form of Dispatcher, which selects a new Dispatcher and executes this.

    For example :
    PHP Code:
    class View_MyMultipageForm extends View
    {
        var 
    $state=NULL;
        function 
    View_MyMultipageForm() {
            if (!isset(
    $_SESSION[get_class($this).'_state'])) {
                
    $_SESSION[get_class($this).'_state'] = 0;
            }
            
    $this->state =& $_SESSION[get_class($this).'_state'];
        }

        function 
    execute(&$request, &$response) {
            if (
    $this->state == 0) {
                
    $dispatcher =& new View_MyMultipageFormFirst($this->state);
            } else {
                
    $dispatcher =& new View_MyMultipageFormSecond($this->state);
            }
            
    $dispatcher->execute($request$response);
        }


  9. #134
    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 kyberfabrikken
    I can see the reason behind this, but I think it's important to realize that a lot of requests won't need an ApplicationController. Therefore the ApplicationController should be optional. To do this, I suggest that the ApplicationController could simply be a form of Dispatcher, which selects a new Dispatcher and executes this.
    What would be "a lot of requests" which "won't need an ApplicationController"? I can think of things like images, stylesheets and js library scripts, but are these not already handle out of the code of your application by apache (or whatever web server you are using).

    Question to ponder: Can we think of apache as the FrontController (first handler for any request, sometimes applies intercepter logic like gzip conpression, sometimes remaps parameter ala mod_rewrite, etc.) and think of everything in a PHP script as an ApplicationController at best?
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  10. #135
    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 sweatje
    What would be "a lot of requests" which "won't need an ApplicationController" (be)? I can think of things like images, stylesheets and js library scripts, but are these not already handle out of the code of your application by apache (or whatever web server you are using).
    Any situation where the relationship between request and screen is 1:1. If you don't let your application maintain state between requests, that would be every request.

    Or did I misunderstand something here ?

    Quote Originally Posted by sweatje
    Question to ponder: Can we think of apache as the FrontController (...) and think of everything in a PHP script as an ApplicationController at best?
    Yes, but in that case there shouldn't be a class called FrontController, should there ? In that case the class named FrontController is in fact the ApplicationController.
    Again ... it really depends on how you use apache. If you set up a htaccess to route all requests (except external ressources like img, js, css) through a single script, which then dispatches to something, then this script may be percieved as the FrontController, right ?
    However, if you have a single php-script for each request, then this is either an ApplicationController or PageController, and apache takes on the role as FrontController.

  11. #136
    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 kyberfabrikken
    Any situation where the relationship between request and screen is 1:1. If you don't let your application maintain state between requests, that would be every request.

    Or did I misunderstand something here ?
    Nope, probably my misunderstanding. Most of my PHP work comes down to two areas: extreamly simple applications which are a single page (and therefore to not require the bulk of (Front|Page|Application)Controller, MVC, etc.) or they are applications which track state, have authentication, actions, views, etc... on down the path we are treading. Realistically then I only think of these patterns in the context of the latter.

    Regards,
    Jason

  12. #137
    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 sweatje
    Realistically then I only think of these patterns in the context of the latter.
    OK, then it makes sense to me, but I believe that there are in-betweens too. Wouldn't complex webpages (such as a forum) have some pages, where the relationship request-screen is 1:1, while other screens would depend on the state?

    For the sake of synchronizing our terminologies - How would you say that the labour should be divided between Front- and Application- Controller ?

  13. #138
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Kyber, if I may make a comment?

    I have the feeling a Front Controller should be minimal, as you may have a number of variable abstract Application Controllers, each abstract AC (Application Controller) having their own, specific responsibility. You can then from those abstractions, base your ACs with more common responsibility suitable for what you need to do yes?

    Such as mentioned earlier, a wizard type AC, that could be one abstraction for example

  14. #139
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    think the I think it is time to sum things up, or atleast clarify a few things. Can we all agree on that the FC's responsibilities are:

    1. Handle (global) intercepting filters (outputbuffering, debugging, logging, timing).
    2. Extract just enough information from the request so we can determine what specific AC and action to execute.

    AC on the other should solely be dedicated to handle the dispatch process which involves:

    1. Handle (local) intercepting filters (authentication).
    2. Execute the action. The action will in turn update the Model, fetch a template and assign template variables to it, and return it to the controller.
    3. Render the template. (Another option is to apply the DispatchView pattern.)

    Comments?
    I think you are pretty close. For the AC, I think the AC is in essence the Action. And the final step should be "Generate the Response" which might be HTML or a redirect or RSS or XML or ...

    Maybe one more time about Page, Application, Input and Front Controllers.

    Page Controller - This is a do it all pattern that organizes the various parts into some best practices. You could say that every PHP page is a Page Controller of sorts, although it may be organized in a different way than the Page Controller pattern lays out.

    Application Controller - This is a controller pattern that is focused on solving the problem of "pages" with complex request and state. A wizard is a common example, but in web applications a multi-page form (such as checkout) would be a better example. It can obviously handle simpler "pages" as well so it is often implemented generally to deal with all pages (complex and simple).

    Front Controller - This extracts the common front end code in Page Controllers and centralizes it into a single script. That is why you see the Front Controller / Application Controller combo (Struts) as the next step up alternative to the integrated Page Controller.

    Input Controller - This is a Fowler term to come to grips with both the Page and Front controllers that handle requests. I get the sense that it simply means a controller that does something based on the request. See PoEAA(61). However in PHP the Application Controller has a little Input Controller in it as well.

    This all leads me to PHP which I believe implements these patterns in a specific way because of the multi-script (vs single compiled executable) nature of PHP applications. I think Jason Sweat has called it the Double Dispatch (or Double Switch) style. This is because an additional and central job of a Front Controller is as a script loader for the action requested (which is a controller as well). Both of these controllers end up being Input Controllers because of the practical need of the second controller to inspect the request, session, etc. to decide how to generate the response.

    Because this is slightly different than how Java does things, the Intercepting Filter pattern has never seemed to apply very well to PHP controllers. PHP controllers tend to internalize the filter chains if they implement them.
    Christopher

  15. #140
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I'd like to change that to :
    1. Handle (local) intercepting filters (such as authentication).
    2. Execute. This may result in an update of the model-layer. If the application is to be REST-full, this should result in a redirecting response. (See #3)
    3. Provide a response. This may be either a redirect or rendering of a View. The View may be a TemplateView or a ServerPage.
    Yes, this sounds more reasonable
    Quote Originally Posted by kyberfabrikken
    So, the FrontController selects an ApplicationController, which then selects a Dispatcher. The Dispatcher is then executed.
    I see. But what do you think about moving the whole dispatch process to the AC? Since the dispatch process is only about including a template and assigning a bunch of template variables, no? Would that result in too much code duplication?
    Quote Originally Posted by kyberfabrikken
    From #2 it seems that you believe that FrontController should map the Request to two objects. Namely ApplicationController and Action.
    Yes, since the AC may have more than one 'route' to go, we need to decide what route that is. E.g, when I create a new thread on this forum (or submit a reply), I have 3 'routes' to choose from.
    1) Preview my post
    2) Submit my post
    3) Manage attachments
    The action variable decides which one of these the client wants to do. The URL may look like this: example.com/index.php?controller=thread&action=preview

    Am I making sense?

  16. #141
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think Action and Dispatcher are abstract parts of controllers that may or may not be separate classes depending on the implementation. In our sense I think the Front controller dispatches an action which is the Application Controller. The Application Controller may turn around and dispatch things, but that is beyond our current scope.
    Christopher

  17. #142
    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 Overrunner
    Yes, since the AC may have more than one 'route' to go, we need to decide what route that is. E.g, when I create a new thread on this forum (or submit a reply), I have 3 'routes' to choose from.
    1) Preview my post
    2) Submit my post
    3) Manage attachments
    The action variable decides which one of these the client wants to do. The URL may look like this: example.com/index.php?controller=thread&action=preview
    That is not what I would understand as an Application Controller. In your above example, each url maps to a single screen, even though you have multiple url's. The Application Controller doesn't come into the picture until the situation where one url could map to multiple screens, depending on the application state. An example could be a multi-page form (aka. a wizard). In a web-application I would say that theese situations are fairly uncommon.

    Have a look at the following quote :
    Quote Originally Posted by M. Fowler, PoEAA (381)
    When to Use It
    If the flow and navigation of your application are simple enough so that everyone can visit any screen in pretty much any order, there's little value in a Application Controller. The strength of an Application Controller comes from definite rules about the order in which pages should be visited and different views depending on the status of objects.
    Compare the following two url's :
    example.com/index.php?controller=thread&action=preview
    example.com/index.php?view=PreviewThread
    The latter could be solved with a simple FrontController -> Dispatcher architecture. In fact it could be handled by the code we have assembled so far. And as you may notice ; So can the former. The fact that you are using two variables, rather than one doesn't really change anything. "controller" simply acts as a namespace for "action" - together they make up the request.

    Quote Originally Posted by arborint
    I think Action and Dispatcher are abstract parts of controllers that may or may not be separate classes depending on the implementation. In our sense I think the Front controller dispatches an action which is the Application Controller. The Application Controller may turn around and dispatch things, but that is beyond our current scope.
    I fully agree to that.

    Quote Originally Posted by Dr Livingston
    I have the feeling a Front Controller should be minimal, as you may have a number of variable abstract Application Controllers, each abstract AC (Application Controller) having their own, specific responsibility. You can then from those abstractions, base your ACs with more common responsibility suitable for what you need to do yes?
    I think we agree, except that you use the word ApplicationController, where I would use Dispatcher.

  18. #143
    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 kyberfabrikken
    An example could be a multi-page form (aka. a wizard).
    In a web app wizard (eg an order script) do you think that could be handled by a micromanaging intercepting fileter? That is, if we give our intercepting filters the ability to redirect as they please, we won't need to worry about having a framework specifically for ApplicationControllers? (Or from the other way around, we let Intercepting Filters act as Application Controllers )

    Douglas
    Hello World

  19. #144
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I went through the files that kyberfabrikken posted and tried to squeeze things down as much as I could and still maintain the basic capabilities. I've tried to remove as many constants from the code as I could so it is configurable to individual tastes for parameter, file, class and directory names.

    The major change was to reduce the mappers down to two files: a DefaultMapper class that just includes PHP files and an ActionMapper class that dispatches Command objects. The DefaultMapper cheats by using itself as the Command object. The mappers take a parameter specifying the base directory of the files and a parameter specifying the default action.

    The Front Controller is reduced to accept a single mapper and the action parameter you want to dispatch on. It looks like this:
    PHP Code:
    class FrontController {
        var 
    $action_param;
        var 
    $mapper;

        function 
    FrontController(&$mapper$action_param) {
            
    $this->mapper =& $mapper;
            
    $this->action_param $action_param;
        }
            
        function 
    execute(&$request) {
            
    $dispatcher =& Handle::resolve($this->mapper->getHandle($request->get($this->action_param)));
            if (
    method_exists($dispatcher'execute')) {
                
    $response =& new Response();
                
    $dispatcher->execute($request$response);
                
    $response->execute();
            }
        }
    // end class FrontController 
    It is called like:
    PHP Code:
    // action=foo does (conceptually):
    // 1. include('actions/foo.php'); 
    // 2. $foo = new foo; 
    // 3. $foo->execute($request, $response);
    $controller =& new FrontController(new ActionMapper('actions/''default'), 'action');
    $controller->execute(new Request()); 
    The Front Controller uses basic Handle, Request and Response classes so it is actually pretty expandable. Thanks to kyberfabrikken the Response class allows redirects and headers to be set. The DefaultMapper uses kyberfabrikken's output buffering to gather the output of the included file and pass it to the response just like regular actions.

    Even though it is supposed to be minimal I added a couple of "features." kyberfabrikken had hard coded mapping the action "foo" to something like a file Action/foo.php and class fooAction. So I added the ability to specify prefixes and suffixes to the action when the mapper constructs the file name and class name. I also added the ability to have an external data map that specifies mappings rather than generating the file and class names from the action. It takes an array, so you could read in an INI or XML file for mappings if you wanted to. Maybe bloat, but it was a small additional function and I wanted to cover most options.

    Take a look at the code and try it out. I included examples of both the ActionMapper dispatching actions and the DefaultMapper including pages. Please post any changes or requests for changes, what you like and don't like. I'd be interested to see if cadmiumgreen could actually use this code for his news and links?

    You can download the code here

    I still feels like it needs a few more rounds and there are still many issues such as needing unit tests, should there be pre and post filters, how to support URL generation, how/where to allow for access control, etc. etc.
    Christopher

  20. #145
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    That is not what I would understand as an Application Controller. In your above example, each url maps to a single screen, even though you have multiple url's. The Application Controller doesn't come into the picture until the situation where one url could map to multiple screens, depending on the application state. An example could be a multi-page form (aka. a wizard). In a web-application I would say that theese situations are fairly uncommon.
    Aha, now I think I too understand what an AC really really is Thanks for the explanation!
    Quote Originally Posted by arborint
    You can download the code here
    Thanks for the code! I have a question though: I don't understand this particular row:
    PHP Code:
    $dispatcher =& Handle::resolve($this->mapper->getHandle($request->get($this->action_param))); 
    You return a handle from the mapper, and then you immediately resolve it. What is the point of that? Isn't it easier to just return an instance of the class you want instead of first creating a handle, and then creating the object?
    Quote Originally Posted by arborint
    should there be pre and post filters, how to support URL generation, how/where to allow for access control, etc. etc.
    I think the (global) intercepting filter should be implemented at FC level since those should be executed on every request.

    Also, could you explain the purpose of the $map in example_action_map.php?

    Thanks

  21. #146
    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 have looked at the changed code from arborint, and I have some observations/comments.

    The first thing I see, is that you have disposed of the abstract RequestMapper and instead coupled the FrontController directly with a concrete mapper, namely the ActionMapper. The result is that the dependency between FrontController<->RequestMapper now is concrete, rather than abstract. This may make the code easier to read, but it surely makes it less flexible.

    Consistently you have disposed of the abstract Dispatcher class, and instead the ActionMapper would always return an Action. There is one quirk however - instead than directly returning the Action, the Mapper does in fact return a Handle to it. Overunner already mentioned the strangeness about this, and I concur - it is completely needless.

    I do think that I know why you do it however. The confusion stems from Fowlers definition of a FrontController. He states that the FrontController selects a Handler. This Handler however is not the same as a Handle (In the WACT::Handle sense). The Handler is just another name for Controller and completely synonymous with my use of Dispatcher (which Fowler don't use for some reason). So the Handler is really your Action.
    As a note, you seem to use Action synonymous with my use of Dispatcher, while I use Action about a specific type of Dispatcher. While you don't distinguish between a View-type Dispatcher and a TransactionScript type Dispatcher, I do. And my name for TransactionScript is Action. I'm sure that the reason why you don't distinguish is because the added seperation also adds to complexity. I agree that this is so, but I would still say that this is a pretty basic need. At least I think that we should design the application such that it is possible to "upgrade" to use two types of Dispatchers when the need emerges. The way I have done this is by having an abstract Dispatcher, and a concrete Acion, which extends from it.

    In the FrontController you pass an action_param to the mapper, which I find completely disasterous for the whole setup. The RequestMapper's (~ActionMapper's) responsibility is to select a Handler (~Dispacther, ~Action) from the incomming Request. Therefore the FrontController shouldn't decide which parameter to look for in the Request - it should be the RequestMapper that decides this.

    There has been some discussion already about filters, but I think it would be wise to leave that subject out (at least for a start). It's an optional addition to the FrontController pattern, not something that needs to be part of it. I think it would be better to first decide on the FrontController's architecture before adding on to it.

  22. #147
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    666
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    First off, on behalf of what I am sure are many lurkers I would like to thank the many participants in this thread. Mixing abstract discussions with concrete code is a good thing.

    aborint,
    What motivated you to restrict FC to one mapper? I know one person's feature is another person's bloat but it seems to me that allowing multiple mappers could be useful. A post number would suffice. It's sometimes hard to follow all the points.

    in general,
    I wonder if it's time to add a Config object to the project? The apps I have seen usually have some sort of configuration file which is edited on a per deployment basis. Holds things like database passwords and working directory paths. Something like:
    $config = new Config();
    $fc = new FrontController($config);
    ...
    $dispatcher = Handle:Resolve($handle,$config);

    Just a suggestion.

    And there may be a similiar need for a Session object.

  23. #148
    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 ahundiak
    aborint,
    What motivated you to restrict FC to one mapper? I know one person's feature is another person's bloat but it seems to me that allowing multiple mappers could be useful. A post number would suffice. It's sometimes hard to follow all the points.
    That puzzled me aswell. Especially since arborint was the one who moved the chain into the FrontController in the first place. As you can see from one of my earlier posts, I suggested that a specialized mapper, which is infact a stack of other mappers, could be used. This can still be done with the current setup. In fact I support doing that, rather than letting the FrontController do the job.

    Anyway. I took some time to further slash the code, provided by arborint down a bit. I also made three changes. 1) I removed the action_param from the FrontController and put it in the Mapper instead. 2) I let the Mapper return the Dispatcher (Action) rather than a Handle to it. I also removed the Handle class completely. 3) I removed the DefaultMapper, since it really isn't needed, after arborint gave ActionMapper a default_action property.

    What I didn't do, though tempted was. 1) re-introduce an abstract RequestMapper class, that the ActionMapper would inherit from and 2) re-introduce an abstract Dispatcher-class, which the the Action would inherit from. If we port the code to php5, they could be changed from abstract classes to interfaces.
    What is the general feeling about this issue ?
    Attached Files Attached Files

  24. #149
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    666
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    I'm fortunate enough to be able to do all new development under PHP5 so interfaces get my vote. I'm willing to port the frame work to PHP5 whenever things start to stabilize. All those &'s bring back many not so fond memories.

  25. #150
    SitePoint Zealot Overunner's Avatar
    Join Date
    Mar 2004
    Location
    Sweden
    Posts
    180
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Where/How should we add support for execution of multiple actions? Probably too soon to ask, but with the current setup I don't see an easy/elegant solution.


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
  •