SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    SitePoint Evangelist ClickHeRe's Avatar
    Join Date
    Mar 2005
    Location
    Ottawa, Canada
    Posts
    580
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation MVC + arborint skeleton: Access Questions

    Ok, I'm back from a couple months away and I missed the excellent threads on the MVC stuff.

    After catching up with all the threads, I have started exploring arborint's code that you can find in this thread http://www.sitepoint.com/forums/show...66&postcount=6

    Now the way I plan on working is that the handler is really a page handler and I want to incorporate the path mapping into there so that the front controller only sees the "page" in index.php/page/action/extra/params. He then loads the good page handler (if it exists, all error stuff goes here like the ActionMapper does, which will be a PageMapper in my case). The map is then a parameter of the Page Class and it is mapped against the Request object path using the path mapper type of algorithm. This enables minimal array size for the mapping as the map is only concerned with this particular page's actions and mapped extra parameters.

    Now the big question is Access control. I think I will use a User class that will be created at the same level as the Request and Response and sent in the Locator for easy access everywhere (see frontcontroller example code).

    The User system has levels (after being authenticated successfully else he's a guest) and permissions. Now the way I see it is that the level part has to be trapped in the front controller to limit access to the page if the person doesn't have suffiscient access rights (admin privilèges for example to the admin section). It could redirect them to an access forbidden page or redirect them to the index page.

    The second access type I would like is a user by user case where they can have access to certain actions that must necessarily be intercepted in the PageHandler where the action is dispatched. Again, if insuffiscient privilèges are detected, the user could be redirected to the default action or another page stating, you can't do this, you don't have access.

    The problem in both cases is how to map the page/action access vs the user rights/permissions. Re-routing when an access forbidden page/action is selected could be with a redirection to a default page/action.

    Also another though in path mapping is what happens if the user types in index.php without a page (execute the default non error page) or uses index.php/page without an action, where it needs to execute the default action (provided that the user has access to the default action which normally he should, because if not, then in theory he should be blocked at page level).

    Just throwing ideas around as I haven't had time to get down to it and would like some thoughts on how this could all work together with keeping the basic skeleton code achieved in arborint's archive.

    Thanks for any input on the problem of security in those beautiful frameworks.

    N.B. I consider myself a noob in frameworks as I haven't built anything myself apart from experimental code in form validators/generators, and an XML/XSLT templating system.

    David

  2. #2
    SitePoint Guru
    Join Date
    Aug 2005
    Posts
    986
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think it isn't a good idea to put something in a framework that can only be used for one thing. Rails uses filters, "hooks" that can be defined for controllers (pages).

    Code:
    class MyController < ApplicationController
       before_filter :authenticate
    
       def authenticate
           # Authentication code here. This will be executed before any action in this controller
       end
    
       # ...
    end
    If you implement it this way your framework will be more "dynamic" because everyone can define his own method of authentication. And filters are useful when you don't have authentication too.

    You could put an
    Code:
    redirect_to :action => 'index'
    in the authentication method that redirects the user to the index, or you could redirect to a not-authorized page with a link to the login page.

  3. #3
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Also, I have applied the Intercepting Filter to allow for pre and post processing of a given Controller [MVC] which has worked...

    I get the impression that where you have the pattern MVC and you need to apply rules - validation for example - you either have the choice of Decorating the Controller in question, or apply the filtering.

    With Decoration you get more flexibility but less re-use of code long term, quite the opposite with filtering as I see it

  4. #4
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have only used the code on one small site to see if actually it worked. I did the same thing you did, which is to create an UserAccess object and register it with the Locator. That way it is injected into every dispatched Command and available if needed.

    I added some code into the FilterChain in front of the FrontController that checks basic access to actions and changes the action param value to an appropriate error action if denied. That's the front line of Access Control and is how I handled your routing question. You could add the same thing in front of a PageController. This would occur after the PathInfoMapper so the action would already be assigned to a Request var.

    Then various pages use the UserAccess object via the Locator for more fine grained control. For example, on an Administration Menu different user types see different composite views.

    This code was never meant to be a framework, but more of a code base that you could create your own framework from. I should also not that I cannot take credit for a lot of the good code in there from the Skeleton threads (but you can blame be for the bad code ). There is a more recent version here that adds a file upload example that someone asked for and a little code cleanup.
    Christopher

  5. #5
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Fenrir2
    I think it isn't a good idea to put something in a framework that can only be used for one thing. Rails uses filters, "hooks" that can be defined for controllers (pages).

    If you implement it this way your framework will be more "dynamic" because everyone can define his own method of authentication. And filters are useful when you don't have authentication too.

    You could put an redirect_to :action => 'index' in the authentication method that redirects the user to the index, or you could redirect to a not-authorized page with a link to the login page.
    I'm not sure about not having things that can only be used for one thing? There are lots of thing in frameworks that are very specific use and I don't see a problem with this if the code is clean.

    I agree with the "hooks" concept and the code being refered to does allow this sort of thing.
    Christopher

  6. #6
    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 elaborating quite a lot on the "skeleton" code since our longest-thread-ever-on-sitepoint-discussion. I deal with authentication in the same way as described, through a filter around the frontcontroller. authorization happens deeper down the application, whenever it's needed. That could be as simple as a second filter around the FC for a application-wide accesscontrol, or it could be within each handler.

    I have been toying with a solution where the handlers are created by a factory. This factory could then be equiped with a securitymanager, which could determine if the handler need authorization or not. If it does, it will return a security-decorator wrapping the actual handler. eg :
    PHP Code:
    class ActionFactory
    {
        var 
    $securityManager;
        function & 
    createAction($actionName) {
            
    $this->loadClass($actionName);
            
    $action =& new $actionName();
            if (!
    is_null($this->securityManager) && $this->securityManager->isSuspicious($action)) {
                return 
    $this->securityManager->decorate($action);
            }
            return 
    $action;
        }
    }

    class 
    SimpleSecurityManager
    {
        function 
    isSuspicious(&$action) {
            return 
    is_object($action) && method_exists($action'isSecure') && $action->isSecure();
        }
        function & 
    decorate(&$action) {
            return new 
    AuthFilter($action);
        }
    }
    /**
       * @implements IController
       */
    class AuthFilter
    {
        var 
    $next;
        var 
    $realm "restricted";
        function 
    AuthFilter(&$next) {
            
    $this->next =& $next;
        }
        function 
    execute(&$request, &$response) {
            
    $user =& $request->identity->getUser();
            if (
    is_null($user->getUUID())) {
                
    // anonymous user. prompt login
                
    $response->setStatus(401);
                
    $response->setHeader("WWW-Authenticate""Basic realm=\"".$this->realm."\""TRUE);
                return;
            }
            
    $this->next->execute($request$response);
        }

    You could rewrite that to replace the factory with a dependencyinjector, especially if you use php5 anyway. (DI and php4 is an odd couple)

  7. #7
    SitePoint Evangelist ClickHeRe's Avatar
    Join Date
    Mar 2005
    Location
    Ottawa, Canada
    Posts
    580
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the replies, I had thought about the Filtering in front of the controller and I too think it's the best approach since you can add any extra layer over it when needed. How would you suggest saving the mapping between level/page access at front controller level and permission/action at page level ? A registry pattern object (used elsewhere for config matters).

    The code was probably never meant to be a framework, but it's still a good start to get on par with the concepts around having a flexible one. Debating is the best part in all these forum posts and will surely help people around in making them better at all this and gving them ideas. I'm not a programmer, so all this is hobby stuff which is why I like it, no pressure and it's fun to learn and will serve me to build my personal sites and PHP projects. I've got a big one that I would like to recode entirely with these concepts to test my personal framework solution.

  8. #8
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I have been elaborating quite a lot on the "skeleton" code since our longest-thread-ever-on-sitepoint-discussion. I deal with authentication in the same way as described, through a filter around the frontcontroller. authorization happens deeper down the application, whenever it's needed. That could be as simple as a second filter around the FC for a application-wide accesscontrol, or it could be within each handler.

    I have been toying with a solution where the handlers are created by a factory. This factory could then be equiped with a securitymanager, which could determine if the handler need authorization or not. If it does, it will return a security-decorator wrapping the actual handler. eg :

    You could rewrite that to replace the factory with a dependencyinjector, especially if you use php5 anyway. (DI and php4 is an odd couple)
    I like this idea of having some standard way of adding Access Control. It seems like on the front end (before the FC) that there are a couple of different ways (like Mappers) that you could do Access Control:

    1. Simple check such as if user is signed in
    2. Some sort of check of the action to allow access to only certain areas (e.g. "admin/*" applies controls to all admin actions)
    3. Map based lookup where the access control are looked up based on a map of the actions.

    But ultimately some sort of rule based system where you write any Validator Rules you want and add them to the Acces Control Filter that runs before the FrontController. You could then inject that filter with a Locator (which my current fork of the Skeleton uses) or DI, and then apply rules to it for more fine grained view-level control.
    Christopher

  9. #9
    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
    But ultimately some sort of rule based system where you write any Validator Rules you want and add them to the Acces Control Filter that runs before the FrontController.
    At first I tried to mirror the InputValidator class and had an addRule() method in the SimpleSecurityManager class, but I skipped that again.
    A better way to go could be to replace the securityManager var in the ActionFactory above with an array. That way you could add several different types of securitymanagers, which each might have different detection-rules (ways to determine if a controller should be wrapped with authentication) and types of authentication (In my example AuthFilter issues an HTTP-auth, but that could be a pretty html-form instead, or a redirect to a loginform or whatever)
    You could ofcourse divide it down further, so that the rules were separated from the authtype. Perhaps by passing the authtype as a param to the rule (SecurityManager) ?
    That would end up looking something like :
    PHP Code:
    class ActionFactory 

        var 
    $filters = Array(); 
        function 
    addFilter(&$filter) {
            
    $this->filters[] =& $filter;
        }
        function & 
    createAction($actionName) { 
            
    $this->loadClass($actionName); 
            
    $action =& new $actionName(); 
            for (
    $i=0,$l=count($this->filters); $i $l; ++$i) {
                    if (
    $this->filters[$i]->isSuspicious($action)) {
                            return 
    $this->filters[$i]->decorate($action);
                    }
            }
            return 
    $action
        } 


    class 
    SimpleSecurityRule 

        var 
    $decorator;
        function 
    SimpleSecurityRule($decorator "HTTPAuthFilter") {
            
    $this->decorator $decorator;
        }
        function 
    isSuspicious(&$action) { 
            return 
    is_object($action) && method_exists($action'isSecure') && $action->isSecure(); 
        } 
        function & 
    decorate(&$action) { 
            
    $decorator $this->decorator;
            return new 
    $decorator($action);
        } 
    }

    ...

    usage :
    $mapper =& new PathInfoMapper();
    $mapper->setFactory(new ActionFactory(new SimpleSecurityRule()));
    $frontcontroller =& new FrontController($mapper);
    $frontcontroller->execute(); 
    As for the accescontrol-filter, I put that responsibility in the factory (in a way it's a filter around the factory). I think that makes sense, especially in regards to composite views, since that way you will get the authentication-check even on included sub-controllers deeper down your application. (Given that you use that same factory for instantiating)

  10. #10
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    At first I tried to mirror the InputValidator class and had an addRule() method in the SimpleSecurityManager class, but I skipped that again.
    A better way to go could be to replace the securityManager var in the ActionFactory above with an array. That way you could add several different types of securitymanagers, which each might have different detection-rules (ways to determine if a controller should be wrapped with authentication) and types of authentication (In my example AuthFilter issues an HTTP-auth, but that could be a pretty html-form instead, or a redirect to a loginform or whatever)
    You could ofcourse divide it down further, so that the rules were separated from the authtype. Perhaps by passing the authtype as a param to the rule (SecurityManager) ?
    That would end up looking something like :

    As for the accescontrol-filter, I put that responsibility in the factory (in a way it's a filter around the factory). I think that makes sense, especially in regards to composite views, since that way you will get the authentication-check even on included sub-controllers deeper down your application. (Given that you use that same factory for instantiating)
    Are you sure this complexity is needed. It seems like a simple filter with a plugin Rule in front of the Front Controller that rewrote the action param would deal with most every case. The rules could be as simple or complex as needed, and the common rules (e.g. IsSignedIn() ) could be prebuilt.

    For any Access Control after the Front Controller things get so appliation specific that Rules would probably be the best solution there as well. I worry about building-in a solution rather than wrapping one around existing simple code.
    Christopher

  11. #11
    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
    Are you sure this complexity is needed. It seems like a simple filter with a plugin Rule in front of the Front Controller that rewrote the action param would deal with most every case.
    I don't really see it as being that complex ? There are two classes involved in the example above - The factoryclass would be nice to have for other reasons aswell, so we really shouldn't count that. That leaves us with just one.

    Quote Originally Posted by arborint
    I worry about building-in a solution rather than wrapping one around existing simple code.
    I'm actually just extending the mapper a bit, in that I pass a factory to the mapper, rather than let the mapper be a factory as is the case with the original skeleton-thread-code.
    As I noted before, I think there may be several benefits of this apart from this access-control thing.

    Quote Originally Posted by arborint
    For any Access Control after the Front Controller things get so appliation specific that Rules would probably be the best solution there as well.
    I agree that they get very specific, but I don't see how that conforms with rules. As I see it, rules are general in nature, so I'd rather think that the more specific the condition gets, the less appealing it is to describe it with a set of rules. It's far easier to simply let the programmer write a function for each of theese specific cases.

    A really nice thing about putting the access-control as a filter in the factory is that it gets decoupled from the actual controller. This makes it easy to change later on.

  12. #12
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have been trying to think through how Access Control works a different levels.

    - In the Front Controller it is a filter that changes the action param to a different value based on the what the failure was. It seems more straightforward to me to sit in front of the FC and not get involved in mapping or dispatching.

    - For a Page Controller I'm not sure a filter is necessary. It really depends on whether the Page Controller has internal error logic or if it is dispatching sub-contollers. If it has its own error logic then just a straight Validator or Rule will get a true/false for Access Control. Maybe something like you are suggesting would work better if it had sub-controllers.

    - Finally for fine grained Access Control within a Controller or View probably just needs a Rule to determine if a specific condition is met.
    Christopher

  13. #13
    SitePoint Evangelist ClickHeRe's Avatar
    Join Date
    Mar 2005
    Location
    Ottawa, Canada
    Posts
    580
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At the page controller level, I think there is still a need to have a kind of filter or way to change the action performed if the user doesn't have access to that action (index.php?/page/action/extra parms/...), the same way the page is rerouted in case the user doesn't have access at the page level in the FC.

  14. #14
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ClickHeRe
    At the page controller level, I think there is still a need to have a kind of filter or way to change the action performed if the user doesn't have access to that action (index.php?/page/action/extra parms/...), the same way the page is rerouted in case the user doesn't have access at the page level in the FC.
    I am assuming that by "page controller level" you mean a controller dispatched by a Front Controller and not an actual Page Controller (no FC). I agree at that level there is often a need to change things based on Access Controls. But that would usually just be part of the Action/Controller selecting a View or a View selecting a sub-View. That's why I think Rules would work best at all levels.

    In this Skeleton code, the App Controller is Rule based, so you could add security rules as part of the state/transition logic very easily. For example, the first Rule could be an access check to see if the user is signed or in a certain group -- other presentation rules would follow.

    In front of the Front Controller I was thinking of something like this:
    PHP Code:
    // the User class would probably be a gateway to session vars
    $UserAccount =& new UserAccount();
    // create filter with access to User info
    $UserAccessFilter=& new UserAccessFilter($UserAccount );
    // go to sign-in page if not signed-in
    $UserAccessFilter->addRule(new RuleUserIsSignedIn('signin')); 
    // go to error page if not an editor
    $UserAccessFilter->addRule(new RuleUserInGroup('editor''error'));

    // you could execute this before the FC to rewrite the action param on errors
    $UserAccessFilter->execute($Locator);
    // FC gets passed, default, 'signin' or 'error' action params
    $FrontController->execute($Locator);

    // or add to a chain with the FC
    $HandlerChain->addHandler($UserAccessFilter);
    $HandlerChain->addHandler($FrontController);
    $HandlerChain->execute($Locator); 
    In a Controller or View you could just use the rules
    PHP Code:
    $rule = new RuleUserInGroup('editor''');
    if (
    $rule->isValid()) {
        
    // show editor options
    } else {
        
    // no editor options

    I'm not sure this is the best way to deal with this, but it would reuse the simple parts (like the Rules and Validator) that the existing Skeleton uses. I think I would need to understand what the common use cases were. Let me know if this makes sense to you -- if so I could maybe create an Access Control example.
    Christopher

  15. #15
    SitePoint Zealot
    Join Date
    Aug 2005
    Location
    South Africa
    Posts
    185
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I added some code into the FilterChain in front of the FrontController that checks basic access to actions and changes the action param value to an appropriate error action if denied. That's the front line of Access Control and is how I handled your routing question. You could add the same thing in front of a PageController. This would occur after the PathInfoMapper so the action would already be assigned to a Request var.
    I'm trying to understand this approach, would it look something like the following?

    PHP Code:
    $Locator =& new Locator();
    $Locator->set('Request', new Request());
    $Locator->set('Response'$Response = new Response());
    // To use for finer grained access crontol elsewhere in the app
    $Locator->set('AppAuth'$AppAuth = new AppAuth());
    $Controller =& new FrontController(new ActionMapper('action/''home''error'));
    // To change the current action and redirect to login screen for incorrect authentication
    $Controller->addFilter(new FilterAppAuth($AppAuth));
    $Controller->execute($Locator);
    $Response->out(); 
    Many thanks

    --
    lv

  16. #16
    SitePoint Zealot
    Join Date
    Aug 2005
    Location
    South Africa
    Posts
    185
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Apologies Arborint, I seemed to have been busy typing and did not see your last reply. That pretty much awnsers my question

    --
    lv

  17. #17
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lvismer
    Apologies Arborint, I seemed to have been busy typing and did not see your last reply. That pretty much awnsers my question
    No, excellent. I forgot to register the UserAccessFilter with the Locator like you did so it is injected into all of the controllers. That would allow finer grained Access Control within the controllers.
    Christopher

  18. #18
    SitePoint Zealot
    Join Date
    Aug 2005
    Location
    South Africa
    Posts
    185
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Could one not also do the following. Basically my context object is a WebLocator (service locator) with request, response and session objects already set.

    The idea is to decorate the FrontController like DL, Kyber and Arborint (etc.) have said in the past to do the initial authentication. At the same time one registers a user access object for fined grained authorization later in the app.

    Something like this:

    PHP Code:
    class AppAuthenticator implements IHandler
    {
        private 
    $decorator;

        public function 
    __construct($decorator)
        {
            
    $this->decorator $decorator;
        }

        public function 
    execute(Context $context)
        {
            
    // Get a user object and check if the user has been Authenticated
            // The user object will most probably contain some session info and other authorization
            // methods using the rules and validator stuff
            
    $user = new UserAccess();
            if ( !
    $user->hasBeenAuthenticated() ) {
                
    $context->request->set('action''Login');
            }

            
    // Add the user object to the context for using with later Authorization
            
    $this->context->set('User'$user);

            
    $this->decorator->execute($context);
        }
    }

    $fc = new AppAuthenticator(new FrontController(new ActionMapper('../actions/''Main''Error')));
    $fc->execute($context = new Context());
    $context->response->out(); 
    I am trying to understand all the possibilities.

    Many thanks for your comments,

    --
    lv

  19. #19
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lvismer
    Hi,

    Could one not also do the following. Basically my context object is a WebLocator (service locator) with request, response and session objects already set.

    The idea is to decorate the FrontController like DL, Kyber and Arborint (etc.) have said in the past to do the initial authentication. At the same time one registers a user access object for fined grained authorization later in the app.
    My question is: why decorate? If you look at the execution, there is no difference between:
    PHP Code:
    $fc = new AppAuthenticator(new FrontController(new ActionMapper('../actions/''Main''Error')));
    $fc->execute($context = new Context());
    $context->response->out(); 
    And:
    PHP Code:
    $context = new Context();
    $aa = new AppAuthenticator();
    $aa->execute($context);
    $fc = new FrontController(new ActionMapper('../actions/''Main''Error'));
    $fc->execute($context);
    $context->response->out(); 
    Except with the second I can put these handlers, plus others, into a HandlerChain and run them all Intercepting Filter style. Plus I have removed a dependency because the AppAuthenticator is no longer dependent on the FrontController. That a few less unit tests.
    Christopher

  20. #20
    SitePoint Zealot
    Join Date
    Aug 2005
    Location
    South Africa
    Posts
    185
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    <action>... handing arborint a nice cup of coffee ...</action>

    Quote Originally Posted by arborint
    My question is: why decorate? If you look at the execution, there is no difference between:
    Many thanks, I agree that their is no difference as you have show. I am basically learning here and needed to explore the possibilities, to come to conclusions like you have shown.

    Quote Originally Posted by arborint
    Except with the second I can put these handlers, plus others, into a HandlerChain and run them all Intercepting Filter style. Plus I have removed a dependency because the AppAuthenticator is no longer dependent on the FrontController. That a few less unit tests.
    Once again, thanks for these insights. To understand, the Intercepting Filter then basically implements a Chain of Responsibility, that gets sequentially executed. The way I see it currently, one could then implement it as a series of decorators or as filters that get executed in sequence?

    Apologies if my exploration causes frustration , obviously the reasoning behind the virual coffee.

    --
    lv

  21. #21
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lvismer
    Once again, thanks for these insights. To understand, the Intercepting Filter then basically implements a Chain of Responsibility, that gets sequentially executed. The way I see it currently, one could then implement it as a series of decorators or as filters that get executed in sequence?
    Maybe the pattern gurus can help clarify, but here is my take on these patterns.

    The Decorator is a way to inject a method into a class to modify it a run-time. It is really the run-time equivalant of "extends".

    Chain of Responsibility is an execution chain where the control is in the nodes. Typically each node has a forward() function that it calls to continue the chain or not to stop it. The Chain of Responsibility really an OO switch statement, and to be honest it is often mentioned but I find it as infrequently used as switch statements.

    Intercepting Filter is one pattern name that I think is terrible but I can't think of anything better and most everyone (sort of) knows what it means. Intercepting Filter is an execution chain where the control is in the chain manager. Typically every "filter" is executed and it is an object that is passed to each filter that is modified.

    I have never really understood the use of Chain of Responsibility with controllers and end up always using Intercepting Filter. The reason is that the end result of any controller is to dispatch, so the last thing in the chain is the dispatcher. With Chain of Responsibility you would need to replicate the dispatcher in every node which goes against DRY.

    Quote Originally Posted by lvismer
    <action>... handing arborint a nice cup of coffee ...</action>

    Apologies if my exploration causes frustration , obviously the reasoning behind the virual coffee.
    $response->addContent($template->render('thanks_for_the_coffee.html'))
    $response->out();
    Christopher

  22. #22
    SitePoint Wizard
    Join Date
    May 2003
    Location
    Berlin, Germany
    Posts
    1,829
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Christopher, could you maybe explain in some details how the Response and ResponseChild classes are exactly intended to be used? Thanks in advance.

  23. #23
    SitePoint Evangelist ClickHeRe's Avatar
    Join Date
    Mar 2005
    Location
    Ottawa, Canada
    Posts
    580
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here is my code derived from arborint's skeleton code and remodeled in PHP5.

    Please feel free to comment, modify it, use it, destroy it, ...

    I reused a couple classes and ideas of the skeleton code and changed some parts to fit my needs on the matter.

    ------------
    David
    Attached Files Attached Files
    Last edited by ClickHeRe; Nov 24, 2005 at 12:34.


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
  •