SitePoint Sponsor

User Tag List

Page 7 of 16 FirstFirst ... 34567891011 ... LastLast
Results 151 to 175 of 397
  1. #151
    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
    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.
    Well ... how often do you actually need that ?
    Anyway - The individual Action could create other Action's and execute them. Like ;
    action/multi.php
    PHP Code:
    require_once('action/one.php');
    require_once(
    'action/two.php');
    class 
    multi
    {
        function 
    execute(&$request, &$response) {
            
    $one =& new one();
            
    $two =& new two();
            
    $one->execute($request$response);
            
    $two->execute($request$response);
        }


  2. #152
    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
    Well ... how often do you actually need that ?
    Maybe you're right, I can't actually of too many cases where this would be needed, but I like the idea
    Quote Originally Posted by kyberfabrikken
    Anyway - The individual Action could create other Action's and execute them. Like ;
    Yes, but then you would have to create a new action for every combination of actions you want to execute. If the actions were instead pushed into some kind of an ActionChain and get executed one by one...
    PHP Code:
    class ActionChain
    {
      var 
    $actions = array();

      function 
    register(&$actionInstance)
      {
        
    $this->actions[] = $actionInstance;
      }

      function 
    execute()
      {
        for (
    $i 0$i count($this->actions); $i++)
          
    $this->actions[$i]->execute();
      } 
    Just a thought.
    Anyhow, regarding your code, it doesn't seem good to have markup in the actions. Instead, I think each action should import a template and assign variables to it, thus letting each action be a mini-controller. It would also be an appropriate place to put formvalidation. For instance:
    PHP Code:
      class FooAction extends Action
      
    {
        function 
    execute(&$request, &$response)
        {
          if (
    isFormValid())
          {
            
    $template = new Template('valid.tpl');
            
    $template->assign('result''The form has been successfully posted');
            
    $response->setContent($template->getContent());
          }
          else
          {
            
    $template = new Template('invalid.tpl');
            
    $template->assign('result''Something bad happened');
            
    $response->setContent($template->getContent());
          }
        }
      } 

  3. #153
    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
    Maybe you're right, I can't actually of too many cases where this would be needed, but I like the idea

    Yes, but then you would have to create a new action for every combination of actions you want to execute. If the actions were instead pushed into some kind of an ActionChain and get executed one by one...
    I recognize that you could find a use for this, but I don't think it would be very common. Anyway - if you should need it, it would be a matter of writing a different RequestMapper, which recognized multiple actions in the request, and then return a Dispatcher like the one you outlined in the above post. You're free to do that.

    Quote Originally Posted by Overunner
    Anyhow, regarding your code, it doesn't seem good to have markup in the actions. Instead, I think each action should import a template and assign variables to it, thus letting (...)
    Of course. I copied the code from arborint, and I'm sure that the reason why he made it that way, was to focus on the FrontController. Exactly how the Dispatcher (Action) works was irellevant for that matter.

    You basically have two choices for how the Dispacther should render a view. Either it uses a Template which it pushes data onto - Just like the example you've shown. This is the TemplateView.
    The other way is to simply include a php-file (which is a mix of html and php). This is a DispactherView (aka. ServerPage).

    If you look at the first version of the code (in CVS at sf), you can see how I have suggested a simple ServerPage-Dispatcher.

  4. #154
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Why have cotten, when you can (just as easily) have silk huh?

    Instead, I think each action should import a template and assign variables to it, thus letting each action be a mini-controller.
    Why? Why not just go the whole way, and settle for a controller, whereby that given controller (one of many possible controllers) can have it's own action? In that regard, a given controller in it's self can have one or more actions as well, still.

    I think I had made a comment on this earlier. Think of a dynamically generated Form as you enquire yes?

    It would also be an appropriate place to put formvalidation.
    If you have one or more controllers, you could assign that given controllers (multiple) actions to each part of the Form in question. You may well ask, why would I want to do that? Well, not on every request, for every given visitor who is going to complete that form, well may not need to complete the entire Form, only given parts of it (and I'm not referring to a wizard, step 1.. step 2.. etc type form either ).

    Hope that makes sense, as there is definitely a need for this. It was a requirement in fact for this framework I'm working on at the moment, why I can't post any script you see, based on this framework.

    But at the moment, the implementation is still shaky

  5. #155
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Really excellent. I have done a few more little changes. Here are my comments.
    Quote Originally Posted by kyberfabrikken
    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.
    I don't think it makes it less flexible because the Front Controller implements the Command pattern rather than an interface. All an action object needs to support is the 'execute' method.
    Quote Originally Posted by kyberfabrikken
    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 agree. It is cleaner and easier to understand without it.
    Quote Originally Posted by kyberfabrikken
    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.
    Actually no, this is not why I implemented it. I added the Lazy Include when there was a CoR so every dispatcher did not need to be loaded. It is no longer necessary.
    Quote Originally Posted by kyberfabrikken
    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.
    I don't distinguish for simplicity, but also because don't think it is necessary. The Front Controller dispatches a Commmand, that's all. That Command can be whatever you want. In most cases I think it should be an Application Controller. So I just want to push the dispatcher type decision off onto the Application Controller. I think an Application Controller should do some of the things that your various 'dispatchers' do.
    Quote Originally Posted by kyberfabrikken
    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.
    Excellent. You have cleaned up the dependency correctly.
    Quote Originally Posted by kyberfabrikken
    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.
    I agree. It would be easy enough to add. Another option is to implement the Intercepting Filter outside the Front Controller and pass the front controller to it. That would probably be a better choice.
    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.
    I just don't think it is necessary in a Front Controller. As I said above if you want to add an Intercepting Filter do it outside the Front Controller. If you want to do more dispatching then have the Front Controller dispatch an Input/Application Controller.
    Quote Originally Posted by ahundiak
    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.
    I think things like configuration data and URL generation are better left to some kind of Dependency Injection. We could do a simple Locator class, but something like phemto would be a better solution in the long term.

    I did another pass over kyberfabrikken's last code. I made the DefaultMapper work with his changes, I added back he ability to have an external map rather than generated file and class names (thie example_action_map.php file show actions foo and bar reversed) as I think that is important.

    You can download the code here skeleton2.3.zip.
    Christopher

  6. #156
    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
    The other way is to simply include a php-file (which is a mix of html and php). This is a DispactherView (aka. ServerPage).
    But how do you 'push' data into the page? Or should the DispatchView be used to render static pages?

  7. #157
    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 Dr Livingston
    Why? Why not just go the whole way, and settle for a controller, whereby that given controller (one of many possible controllers) can have it's own action? In that regard, a given controller in it's self can have one or more actions as well, still.
    I'm not sure if I follow you, but do you suggest that each Action should be a fully fledged controller? And that it too can have 'subactions'?
    Sorry but I don't see any reason for this. The actions doesn't need to be that complicated.

  8. #158
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Why? Why not just go the whole way, and settle for a controller, whereby that given controller (one of many possible controllers) can have it's own action? In that regard, a given controller in it's self can have one or more actions as well, still.
    I think you are spot on there. This is just the Front Controller. It solves cadmiumgreen's problem by centralizing the running of PHP files based on an action parameter using the DefaultMapper. It will also execute objects as Commands. These objects can be anything you want (so long as they have an 'execute' method) and should be the controllers that actually do the real work of building the response.
    Quote Originally Posted by Overrunner
    I'm not sure if I follow you, but do you suggest that each Action should be a fully fledged controller? And that it too can have 'subactions'?
    Sorry but I don't see any reason for this. The actions doesn't need to be that complicated.
    It is a "fully fledged controller", whether you like it or not, because that is actually what it does. This point of the code we are building here is to formalize the common parts to you don't have to rewrite them for each page but just focus on the code specific to that page.

    Obviously the next step in this process is to do an Input/Application Controller (I have some code that may be a starting place for that). But we should not continue until we agree that this code is OK. I would like people to take a look at the last code I posted, try it out, and say whether it is actually usable (which DougBTX right said should be a more important requirement than simplicity ).
    Christopher

  9. #159
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would like people to take a look at the last code I posted, try it out,
    Out of the last 3 code refactorings, I've only looked at the first two, and the second of the two looks in better shape in my view, if that's any help?

    Downloaded the 3rd refactoring a moment ago, but I'll not be able to take a look at it at the moment.

    but do you suggest that each Action should be a fully fledged controller? And that it too can have 'subactions'?
    Yes, exactly what I was suggesting You may (think you may) not have a need for this functionality, but trust me, you will at some point in time. Out of all the work I've done with PHP this last 4 months I questioned why?

    Why this and why do I -BEEP- need to go and script that... Why? Apart from doing what is asked, I do manage to pick up a few things from the various conversations I've had

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

    Sorry but I don't see any reason for this. The actions doesn't need to be that complicated.
    On the point of that example Form I gave yes? It isn't a Wizard style form because (for one example) the various parts involved are not sequencial, but are dependent on the visitor or user.

    Now... There coule be any number or types of user, so you now see where I was going with this yes? User A may need parts 1 through to 8, and part 12 and part 13, but user K only needs to complete parts 3, 4 and 5, and depending on a given variable for that given application, they may or may not need to complete part 9 as well

    Now mate, that is complexity, and it's a -BEEP- nightmare. This stuff keeps me awake at night

  11. #161
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Will this skeleton web controller save development time for the person posting in this thread?

    That seems like an important test for any code we write here, imo a typical request that a controller for a web app should be able to help with.

    Douglas
    Hello World

  12. #162
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    Will this skeleton web controller save development time for the person posting in this thread?

    That seems like an important test for any code we write here, imo a typical request that a controller for a web app should be able to help with.

    Douglas
    Actually the skeleton Front Controller will currently dispatch "www.my.com/index.php/foo/" or "www.my.com/foo/" (with mod_rewrite), so yes. All these this are configurable. Just use 'PATH_INFO' as the action parameter like this:
    PHP Code:
    $mapper =& new ActionMapper('actions/''default''PATH_INFO');
    $controller =& new FrontController($mapper);
    $controller->execute(new Request()); 
    I think this URL:
    Code:
    http://foo.com/samepath/myapp/name1/val1/name2/val2/namen/valn
    is a very good reason to have a Request class. It would be trivial to parse the raw command line and add values to the request in any scheme you wanted. Your program would work with regular URLs and custom ones without modification. I could easily add support for this if people thought it was a good idea. Perhaps we should to add an optional Decorator to the Request that could be used for this?
    Christopher

  13. #163
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    aaah, 2K posts. I think I'll leave you guys to it for a bit, you are scaring me

    I'll pop back once I have a couple of projects out of the way: one of which might even be an MVC PHP app; if so, I'll tell you how it went

    Douglas
    Hello World

  14. #164
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I think this URL:
    Code:
    http://foo.com/samepath/myapp/name1/val1/name2/val2/namen/valn
    is a very good reason to have a Request class. It would be trivial to parse the raw command line and add values to the request in any scheme you wanted. Your program would work with regular URLs and custom ones without modification. I could easily add support for this if people thought it was a good idea. Perhaps we should to add an optional Decorator to the Request that could be used for this?
    I agree! Another reason for having a request class is for re-using a certain application or action as a sub-action where the $_REQUEST variable is not present. If you wanted to re-use a menu application on a certain page but force it to a certain state and it was checking $_GET, than you'd be screwed, but with a request/input class that had a set() method, you could change that parameter and customize. Actually, I think that the class should be called Input and not Request, but that's just me. I know that you could set variables in $_GET (maybe?) but that seems like hacking to me.

    - matt

  15. #165
    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 DougBTX
    aaah, 2K posts. I think I'll leave you guys to it for a bit, you are scaring me

    I'll pop back once I have a couple of projects out of the way: one of which might even be an MVC PHP app; if so, I'll tell you how it went

    Douglas
    I can't wait for 2001, A Douglas Odyssey
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  16. #166
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DougBTX
    aaah, 2K posts. I think I'll leave you guys to it for a bit, you are scaring me

    I'll pop back once I have a couple of projects out of the way: one of which might even be an MVC PHP app; if so, I'll tell you how it went

    Douglas
    I think it might take us another 2000 posts to get an Application Controller done! This is already the 5th longest thread ever in this forum and all we have is a tiny Front Controller and a simple Mapper!
    Christopher

  17. #167
    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
    But how do you 'push' data into the page? Or should the DispatchView be used to render static pages?
    Ah - The point exactly!
    TemplateView uses a Controller to push data from the Model, onto the View.
    ServerPages pull data directly from the Model. This is why the ServerPage is also called DispatcherView - It combines Dispatcher (~Controller) with View, in one object.
    This ofcourse is a violation of the notorious MVC-paradigm, but that's a different story.

    Quote Originally Posted by arborint
    These objects can be anything you want (so long as they have an 'execute' method) and should be the controllers that actually do the real work of building the response.
    Yes, and that's probably why we keep mocking eachother about if we should call the object a Handle, Command, ApplicationController, Action or Dispatcher. I'm quite sure that at least from the FrontController's point of view, we mean the same thing.

    Quote Originally Posted by arborint
    I think this URL:
    Code:
    http://foo.com/samepath/myapp/name1/val1/name2/val2/namen/valn
    is a very good reason to have a Request class.
    Really good point. Though an intercepting filter could serve the same purpose.

    Quote Originally Posted by arborint
    I think it might take us another 2000 posts to get an Application Controller done! This is already the 5th longest thread ever in this forum and all we have is a tiny Front Controller and a simple Mapper!
    Why settle for less than perfection - I expect us to make it to the top.

    Quote Originally Posted by arborint
    You can download the code here skeleton2.3.zip.
    I'll have a look at the latest iteration, and post back by then. The time-zones mean that this will likely happen before you come back to this forum.

  18. #168
    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)
    DefaultMapper
    I have renamed the DefaultMapper to ServerPageMapper, since this is what it does. Also - I don't like the way you were having the mapper returning itself. It is clearly two different roles, which are mingled into one class. You made a note on this yourself a couple of posts back. I have taken the consequence and seperated them into two different classes.

    Error-supression
    It is evil. Please.

    FrontController
    Have a look at the FrontController class. In the line "if (method_exists($dispatcher, 'execute')) {", what you really are doing here, is to check if the returned object has a certain feature. The proper, object-oriented way to do this, is to use an interface, and check if the object implements it. Eg: (pseudo PHP5)
    PHP Code:
    interface IDispatcher
    {
        public function 
    execute(&$request, &$response);
    }

    class 
    FrontController
    {
        (...)
        function 
    execute(&$request) {
            (...)
            if (
    $dispatcher instanceof IDispatcher) {
                (...)
            }
        }

    Since we don't have interfaces in php4, we could use an abstract class instead. That's what I did in the first version.

    A thing that has had me thinking a bit is, that the FrontController gets the Request object passed on, but it creates the Response. This makes it different from all the other controllers, which get's both objects passed. That makes me think that the Response should probably be passed on aswell, or the opposite - that the FrontController should create the Request. What do you think about this ?

    ActionMapper
    The implementation, you have made gives the ActionMapper two different operation-modes. It may use a dictionary or it may not. I think that this is clearly two different concerns, and that they should therefore be two seperate objects. I know that you are concerned with the number of classes, but I prefer more classes with less responsibility each, than few classes, with two many responsibilities. If I were in a bad mood, I might even use the word bloat.
    The mere fact that you have presented two different example-scripts for the two uses, clearly supports my claim.

    I have therefore seperated the class ActionMapper into two different classes now. The ActionMapper and the ActionLookupMapper. I suggest that we dispose of the latter, if the need to reduce the number of classes should show ?
    Attached Files Attached Files

  19. #169
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree with all that kyberfabrikken has said (particullary interfaces in PHP5, it just makes more sense). However, should ActionLookupMapper look more like:
    PHP Code:
    <?php
    require_once('ActionMapper.php');
    class 
    ActionLookupMapper extends ActionMapper
    {
        var 
    $map NULL;

        function 
    ActionLookupMapper(&$map$base_path=''$default_action=''$action_param='action') {
            
    parent::ActionMapper($base_path$default_action$action_param);
            
    $this->setMap($map);
        }

        function 
    setMap(&$map) {
            
    $this->map =& $map;
        }

        function 
    doMapping($action) {
            
    $this->file_name $this->base_path $this->map[$action]['file'];
            
    $this->class_name $this->map[$action]['class'];
            
    $this->data = (isset($this->map[$action]['data'])) ? $this->map[$action]['data'] : NULL;
        }

    // end class ActionLookupMapper
    ?>
    In plain-words, why set all those properties when we inherit them, anyway?

    You guys are doing great work!

  20. #170
    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 Ryan Wray
    In plain-words, why set all those properties when we inherit them, anyway?
    You're completely right. It's just a typo (or rather cut&copy-o). There's no sinister plan hidden behind it.

  21. #171
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, I assumed as much. :P

  22. #172
    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
    ServerPages pull data directly from the Model. This is why the ServerPage is also called DispatcherView - It combines Dispatcher (~Controller) with View, in one object.
    This ofcourse is a violation of the notorious MVC-paradigm, but that's a different story.
    But the separation issue between the Model and View could perhaps be solved with a ViewHelper? I've actually no idea how the pattern works but I think Dr Livingston mentioned it?
    Quote Originally Posted by kyberfabrikken
    The implementation, you have made gives the ActionMapper two different operation-modes. It may use a dictionary or it may not. I think that this is clearly two different concerns, and that they should therefore be two seperate objects.
    Could you give an example when I would (should?) need the dictionary to dispatch the request?

    Also I was thinking if we shouldn't add some kind of errorcheck in the ActionMapper if the requested action does actually exist. Something like this:
    PHP Code:
      class ActionMapper
      
    {
        function 
    actionExists($actionName)
        {
          
    $file 'actions/' $actionName '.php';

          return 
    is_readable($file);
        }
      } 

  23. #173
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I need to take a look at the code but all you changes sound fine. Perhaps we should do PHP4 and PHP5 versions of the code? I was going for the minimum files because the interfaces confused people before.

    I like the ActionLookupMapper inheriting the ActionMapper. I may tweek that code so ActionLookupMapper can do both dictionary lookups and fall back to regular mapping. I have found partial remapping very useful in real projects.
    A thing that has had me thinking a bit is, that the FrontController gets the Request object passed on, but it creates the Response. This makes it different from all the other controllers, which get's both objects passed. That makes me think that the Response should probably be passed on aswell, or the opposite - that the FrontController should create the Request. What do you think about this ?
    I think we should discuss whether we implement pre and post filter chains in the Front Controller to make it an Intercepting Filter. If we pass both in both Request and Response objects in, and return the Response object, then you could pre filter the Request and post filter the Response outside the Front Controller. That keeps it small and focused.

    Perhaps we should implement an additional InterceptingFilter type class that creates the Request and Response internally plus contains pre and post filter chains AND the Front Controller inside. Then you could use the simple FrontController or the all-in-one InterceptingFilter?

    Centralized access control is a very practical case that we should be able to support. For example, if the dictionary map contained access control information then an access control pre filter could get data from the map and compare it to data in the session to do the access check. We should be able to support this (though not necessarily actually provide code to implement it). What do you think?
    Christopher

  24. #174
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    In front of my computer
    Posts
    96
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I think it might take us another 2000 posts to get an Application Controller done! This is already the 5th longest thread ever in this forum and all we have is a tiny Front Controller and a simple Mapper!
    You know why ?
    My little finger tells me it's because you're trying to perfect things, which are abstracted from a real application. It's called Premature Optimisation[1].

    Altrough I have many ideas to contribute, but I think that the approach should be changed. You should better try to build a real-world application and then extract the framework. That's how Rails[2] was built and I think it's pretty successful.

    Cheers,
    ... zimba

    [1] http://c2.com/cgi/wiki?PrematureOptimization
    [2] http://www.rubyonrails.com
    participate to the best Php Wiki
    my blog ...

  25. #175
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You know why ?
    My little finger tells me it's because you're trying to perfect things, which are abstracted from a real application. It's called Premature Optimisation[1].
    You are, of course, absolutely right and absolutely wrong.

    You are correct is that we really should have use cases that we must be able to implement. We do have the original cadmiumgreen's (Byron did you spontaneously combust?!?) switch statement and DougBTX (Mr. 2000 woo hoo!) has thrown a few at us. But we really need use cases and more importantly test cases.

    Where you are incorrect is that both kyberfabrikken and I have written frameworks and plenty of production code, so have been through the practical aspects of this already. That is what makes this interesting to me is that we are contributing our code and blending it.
    Altrough I have many ideas to contribute, but I think that the approach should be changed. You should better try to build a real-world application and then extract the framework. That's how Rails[2] was built and I think it's pretty successful.
    If you don't get involved you can't effect what is happening. We are open to ideas. You could make a difference I think. Give us specific comments about the code. Contribute code. Give use cases. Challenge the ideas presented. We are trying to build a simple but useful system that answers with code many of the MVC questions asked.

    If you are interested in Rails then hopefully soon we will get started on an Application Controller which is what Rails' Action Pack is. Rails apps extend the ApplicationController and I think that is the way we are headed as well. I think Rails was built by people who maintained their focus and stuck to "Don't Repeat Yourself". Hopefully you will be able to build a Rails like system out the the code we create here.
    Christopher


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
  •