SitePoint Sponsor

User Tag List

Page 4 of 5 FirstFirst 12345 LastLast
Results 76 to 100 of 120
  1. #76
    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)
    harry fuecks does a good job at explaining mvc. so if you didn't already, go on and read it.
    http://www.phppatterns.com/index.php...leview/19/1/1/

    you won't see a lot of explanation on the model in theese mvc-discussions. that's because it's really outside the scope of mvc. basically mvc is about control-flow in your application.

    about modrewrite : http://www.sitepoint.com/article/910/

  2. #77
    SitePoint Zealot
    Join Date
    Sep 2003
    Location
    Melbourne, Victoria, Australia
    Posts
    115
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    PHP Code:
    require_once('FilterManager.php');
    $fm =& new FilterManager();

    require_once(
    'FrontController.php');
    $fm->setController( new FrontController() );

    require_once(
    'OutputBuffer.php');
    $fm->addFilter( new OutputBuffer );

    require_once(
    'RequestStripSlashes.php');
    $fm->addFilter( new RequestStripSlashes() );

    $fm->execute(); 
    I took a look at your code and I tend to like this implementation. It seems quite straightforward to me. I assume that I can also do the following if I am using PageControllers rather than a FrontController?
    PHP Code:
    // view-events.php

    require_once( 'FilterManager.php' );
    require_once( 
    'Authenticate.php' );

    $fm =& new FilterManager();
    $fm->setController( new ViewEventsController() );
    $fm->addFilter( new Authenticate.php );

    class 
    ViewEventsController() {
        function 
    ViewEventsController() {}
        function 
    execute() {}

    This way I can add different filters to the chain depending on the requirements of the request (eg. secured area, regionalised, language, etc.)

    What would be the drawbacks of this? (besides the obvious duplication of some minimal code).

    Cheers,
    Af.

  3. #78
    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 afro boy
    besides the obvious duplication of some minimal code
    well, that'll be the hole point of using frontcontroller vs. pagecontroller. the frontcontrollers sole purpose is to centralize that kind of logic.

  4. #79
    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 php_programmer
    But someone posted something in this thread a few pages back (I really don't feel like looking) about not needing to use that. At least that's the impression I got out of his last paragraph.
    Would this be the quote you're referring to ?

    Quote Originally Posted by Captain Proton
    you can change the URL naming scheme of your website from something like index.php?page=whatever to /site/whatever by making a change in the FrontController instead of messing around with mod_rewrite for all page controllers
    All he says in that, is that you will have a single point where you can translate the rewritte url, instead of doing it in each pagecontroller. he doesn't imply that you needn't use modrewrite.

  5. #80
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gybbyl
    Alright, a little late, I know, but I had a (personal) revelation and want to verify it.

    Objects of type InterceptingFilter are just the "EE" version of decorators?
    I somehow missed that post of yours. If you wind back 5 posts, you'd see me posting this :

    Quote Originally Posted by kyberfabrikken
    As a sidenote ; Couldn't FilterManager above be considered a fine example of the Decorator pattern ?
    So definately some decoration going on here i suppose ?

    As far as i get it, the Decorator pattern is a very generic pattern, were the InterceptingFilter is more specific to a given problem area (I think it's solely used in relation to the MVC-pattern).

  6. #81
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    eg. secured area, regionalised, language, etc.
    I would imagine that it's the job of a Front Controller it's self to select and mange a language to use ? To decide on a given page is private or not ?

    This isn't the intentions of the Intercepting Filter as I see it

    Also, you have piped a Page Controller directly to the Intercepting Filters, though is this viable ? Are you intending to add all possible Page Controllers to your Filters now ?

    Besides, you'd need to Authenticate prior to execution of a Controller anyways, not the other way around as in your example

    Though I do appreciate that you are new to this level of discussion, I'm in a forgiving mood today

    Anyways, hope I'm of some help to you anyway, if you've any questions either post at this thread, or just PM me and I'll try to help if I can

  7. #82
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Captain,

    A while back in this thread you stated that Mojavi wasn't a true Front Controller implemnetation. I was hoping you would spend some time elaborating on that statement.

    Thanks,

    JT

  8. #83
    SitePoint Member
    Join Date
    Aug 2004
    Location
    On the computer
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ok, there was a bit of discussion before on extending a controller from a filter class..is this ok? in the script I'm making the way everything is put together, this is almost th eonly way to have it work ok. I borrowed what object monkey does with their front controller...kind of the same idea.

    Basically I think I'll have it like this: the required data, just the info from $_GET will go through all the filters, then finally get to the front controller. After it gets there the front controller will choose one of the page controllers (or whatever you want to call them...they are page specific though so..), and call that. Then that will choose the specific command it needs to execute, which will get all required data and then the view iwll be selected. And that's about all. the reason I want it like this is because there are basically two parts to my application, and each of these two parts have different actions that can be done under them. For instance there is a part to modify and view the information added; and so under that part you can add, edit, delete, and view the information. the other section is to add / delete users.

  9. #84
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The FrontController is the application's sole access point to the outside world. This receives user input and would initiate a filter chain (if you're using one) rather than a FrontController being loaded by a filter chain.

    Actually I wish I had the time to write up a "J'Accuse Intercepting Filters" piece but it would have to be long and detailed. Still, don't let me put you off. I'm probably in a minority of one.

    I'd recommend filtering ALL user input - not just GET vars. Every request can predict failry precisely in advance what parameters (keys and values) it should receive from GP&C and can check for values within allowed ranges as well as various checks for missing or alien keys.



    Gee mom, are you SURE you checked those cookies?

  10. #85
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    The FrontController is the application's sole access point to the outside world. This receives user input and would initiate a filter chain (if you're using one) rather than a FrontController being loaded by a filter chain.
    So, you're saying that all filters are executed (pre and post) after the front controller has executed? What do you see as problems when loading a front controller into a filter chain?

    Matt

    p.s. Always wondering about your Dynamic Engine and the posibility of seeing some good examples!

  11. #86
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    So, you're saying that all filters are executed (pre and post) after the front controller has executed? What do you see as problems when loading a front controller into a filter chain?
    It's just semantics really: in this case the FilterManager would actually be the FrontController.

    Quote Originally Posted by mwmitchell
    Dynamic Engine and the posibility of seeing some good examples!
    The DynamicEngine was a very early OOP "brainwave" written when I was pretty green and didn't realise how big personal breakthroughs weren't really so wonderful as they seemed.

    It solved a problem I had with building pages in sections: basically it creates a queue of objects (corresponding to individual page sections or blocks as they are sometimes called). Everything observes everything else so (for example) a Head class can gather a page title and keywords from other page bits. A pipe manager object is also registered as an observer: the actual data being output on the page gets transferred to that.

    I wouldn't make any claims for it whatsoever but feel free to steal anything in the unlikely event that it might be useful. I'd expect it would have some similarities to a filter manager, which also is an object queue at heart.

  12. #87
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by php_programmer
    McGruff, thanks for th einformation. So the front controller starts the filter chain, what is at the end to receive the data? Just want to know how to do this correctly. Thanks again.
    I'm not the best person to ask about Intercepting Filters. I tend to think the pattern is badly defined and conceived - perhaps I've still got some shades of green to deal with...

    Anyway, here's a couple of links:

    Wact Wiki FrontController

    Wact Wiki InterceptingFilter

  13. #88
    SitePoint Member
    Join Date
    Aug 2004
    Location
    On the computer
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hi,

    Ok, I looked at the links. Very interesting.

    Basically, it does say that the last filter of the chain should be a special filter to be called in order to access the application logic. That would basically be like what the example showed in this thread earlier about intercepting filters.

    So then the front controller could initialize them, say in a method called run; and then a method called execute could be called when called by the previous filter. Then it can get started choosing what to do next.

    This all is very interesting. I have been looking at phppatterns.com, and find it is about the best resource for this information. The articles are very informative; and it is interesting to see how many different opinions there are out there.

  14. #89
    SitePoint Zealot
    Join Date
    Sep 2003
    Location
    Melbourne, Victoria, Australia
    Posts
    115
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    WindowMaker, thanks very much for your response - my new friend! I am reasonably new to the OO approach but thanks to this forum I've learnt a lot and come a long way in a short amount of time. Still learning though, as we all are.

    Quote Originally Posted by Widow Maker
    I would imagine that it's the job of a Front Controller it's self to select and mange a language to use ? To decide on a given page is private or not ?
    If I replace Front Controller with Page Controller above, will your statement still be true? (say for a moment that I'm not using a FC aside from the web server).

    Quote Originally Posted by McGruff
    The FrontController is the application's sole access point to the outside world. This receives user input and would initiate a filter chain (if you're using one) rather than a FrontController being loaded by a filter chain.
    Good point. FrontController initiates the FilterManager\Chain. Can a PageController also do the same?

    Take for example that only some pages require authentication. I see three solutions:
    1. Map all these into the FrontController so it knows which Filters to add to the chain
    2. Use seperate PageControllers that know which Filters are required for that page
    3. Use a combination. A FrontController for the secured pages, and a FrontController for the public pages.

    Would that summarise the approaches? This is where I'm at in trying to make a decision.

    Thanks again for your help.

    Cheers,
    Af.

  15. #90
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is a fiddly problem to solve. Following the principle of "resolve anything which is repeated into a single source", you might have a hierarchy of:
    - filters common to ALL requests
    - some more filters common to all requests in a particular site area
    - finally, some filters specifically added for a particular request

    It's quite likely that it can't be defined as neatly as that.

    As you say, there has to be some means of dynamically adding filters to a FilterManager, according to the request (I guess it's possible that a given app might have a constant filter list for all requests, but an architecture which imposes that wouldn't be widely useful). I'm not sure if I know the best solution but I think all three options you mentioned are valid.

  16. #91
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In regards to my earlier statement, authentication of a user if they're logged in or not can be delegated to a Filter ?

    For authenticating if a user can carry out an action is a higher layer task, thus I think it belongs within the Front Controller.

    You could I suppose have it in a Page Controller, but my feeling is that is too far down the application layer for this ?

    Looking at Mojavi for a moment, for public/private pages, this frameworks Actions return a variable to determine which is which, public or private if I remember ?

    I'm thinking that if I have a base Page Controller, and each sub Controller has a variable to determine a page is public or private, the Front Controller can determine prior to dispatching a Page Controller, via the base Page Controller what action to take ?

    PHP Code:
    class PageController {
    function 
    authenticate() { }

    ...
    class 
    AddNewsPageController extends PageController {
    var 
    $policy 'private';
    function 
    Dispatch() { }
    ...
    }
    ... 
    Then Front Controller has something to determine ?

    PHP Code:
    ...
    if( !
    $page -> Authenticate$_GET['Act'] ) ) {
    ... 
    redirect to unauthorised action page ...
    }
    ... 
    This is off the top of my head just now, but it could be something like this ? I think the Front Controller should have the final say in what happens, as if user doesn't have the permission to edit news for example, and a page is private (ie requires permission) then you need to redirect yes ?

    Shouldn't the Front Controller manage this then ? Maybe need more to clear this up I think

  17. #92
    SitePoint Member
    Join Date
    Aug 2004
    Location
    On the computer
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if I were making it I'd probably stick it in the page controller, or in the highest level possible that required authentication. I'm not quite sure what you call what the front controller selects...

    btw I changed my code in my project now so that the fc initializes the filter chain but then the data ends up back at the front controller. So hopefully that's a bit better. now trying to figure out model methods...

  18. #93
    SitePoint Enthusiast NativeMind's Avatar
    Join Date
    Aug 2003
    Location
    USA
    Posts
    80
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Good point. FrontController initiates the FilterManager\Chain. Can a PageController also do the same?

    Take for example that only some pages require authentication. I see three solutions:
    1. Map all these into the FrontController so it knows which Filters to add to the chain
    2. Use seperate PageControllers that know which Filters are required for that page
    3. Use a combination. A FrontController for the secured pages, and a FrontController for the public pages.

    Would that summarise the approaches? This is where I'm at in trying to make a decision.
    Remember, the "FrontController" is not a science with a set of rules to be followed, it is a pattern and you describe that pattern with things it "can" do - but doesn't have to, and based on your implementation can vary quite differently.

    Take for example, Mojavi. Mojavi is a combination between a FrontController and an Application Controller. It does not dispatch to a separate application control, but implements a command-dictionary type design controlled by the file system layout as well as an intercepting filter. For many web applications - ranging from the very small to the very large, this is the architecture you have. You have a homogeneous system and you just want to give it structure. I say homogeneous because you aren't dispatching to other controllers really -- that level of complexity and deepness to the controller is rarely needed.

    Now, another possible implementation of a frontcontroller is just a very "thin" controller that dispatches to different applications (whom in turn have their own application controller). This is a lot closer to a Java application where your applications are very thick, and they just implement an interface to the front controller for receiving information from the web server. I have found that PHP4 applications rarely need this, and in fact -- this is very counterintuitive to PHP's "shared nothing" architecture.

    Remember, a PHP application is completely different than your Java servlet environment where you have a web container and applications running in that container. In PHP, everything is already sitting in the web server and any part in the script you have just as much access and ease of use with web server variables than any other script. Furthermore, a PHP script lasts for but an instant: created on a request, and then destroyed when the request is done so it makes sense to keep the application as lean as possible. Applications who don't keep it lean tend to feel slow and bloated (just try to run any of those PHP ports of Struts and you'll know what I mean). You don't need anything special to get something from the web server, or send something back to be served to the web browser. There is some added bonus from using something in the front, as opposed to just using a superglobal ($_GET, $_POST, etc) but if ya didn't and repeated addslashes() and htmlentities() a few extra times, it wouldn't kill you.

    To wrap things up, a design pattern is just that -- a pattern, a way many people have come to attack a problem with solutions that are all similar. The solutions vary, and yes a frontcontroller "can" do this, and it makes sense to do one thing with the other, but not without it and the debate can never really end. Sometimes, I think a project is good with just Mojavi, sometimes I think a project needs a front controller to dispatch to other applications. Do you put authentication in a front controller? Perhaps, or maybe you dispatch to several applications that do their own authentication and some with no authentication at all.

    P.S. Mojavi's psuedo command for loading modules has its own pluggable authentication/authorization API that you are free to use or not. In fact, that's my favorite part about Mojavi -- things aren't "built in" to the framework, it just provides a nice OO API to plugin your own stuff into Mojavi (a greaty way to keep a PHP project organized in my opinion).

  19. #94
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    The FrontController is the application's sole access point to the outside world. This receives user input and would initiate a filter chain (if you're using one) rather than a FrontController being loaded by a filter chain.
    I just read the Microsoft description of the Intercepting Filter pattern
    and it says it ain't necessarily so:

    "An interesting alternative implementation to the Intercepting Filter pattern uses the Decorator pattern around a Front Controller."

    This probably proves your point that the pattern is "badly defined", since no-one seems to agree on what does what to what. Anyway, the real question is whether the essential functionality of the Front Controller should be in one place or the other. Or perhaps either way would work.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  20. #95
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    The FrontController is the application's sole access point to the outside world. This receives user input and would initiate a filter chain (if you're using one) rather than a FrontController being loaded by a filter chain.
    Another comment to the same statement. After reading Captain Proton's example in post #24 again, I can see that it actually does both: the front Controller loads itself into the chain of decorators. So it's both the initial access point (the run() method) and is also being run as a filter (the processRequest() method).
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  21. #96
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The FrontController, as I understand it, is a single point of access to the app. In the link you gave, "RequestHandler" is the single point of access and so I'd see that as a FrontController. The "concrete controller" I would say is a PageController.

    After reading Captain Proton's example in post #24 again, ... the front Controller ... is both the initial access point ... and is also being run as a filter...
    I wouldn't personally like to treat the FC as both a centralised request handler and as a filter since I think this confuses its role. A class should be responsible for just one thing, as a rule.

    I'm beginning to wonder if the discussion here about InterceptingFilter is following a similar "pattern" to the frequent questions about MVC on these forums, ie it is not providing an immediately clear and intuitive solution. Instead, it seems to be creating more questions than answers. That could be a fault of the pattern itself, how well it is explained, or maybe just part of the learning process.

    In part I think the arbitrary (IMO) separation of pre, core and post processing which leads to InterceptingFilter is responsible for this, but I accept that this is one way of looking at things which suits many people.

    At heart, there is a very simple process: load a bunch of objects each of which carries out an action (including serving the client page).

    The classes should be as independent as is possible, and there will (usually) need to be some means of dynamically configuring the actions/tasks/commands list - whatever you want to call it.
    Last edited by McGruff; Aug 13, 2004 at 20:57.

  22. #97
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    The FrontController, as I understand it, is a single point of access to the app. In the link you gave, "RequestHandler" is the single point of access and so I'd see that as a FrontController. The "concrete controller" I would say is a PageController.
    According to Fowler, the Front Controller has both a Web Handler which is the single point of access and a set of Commands.
    Quote Originally Posted by McGruff
    I wouldn't personally like to treat the FC as both a centralised request handler and as a filter since I think this confuses its role. A class should be responsible for just one thing, as a rule.
    Good point, but it looks to me like the FC's two jobs may be considered one responsibility. The FC is not acting as a filter; it controls main processing after the prefilters and before the postfilters.
    Quote Originally Posted by McGruff
    I'm beginning to wonder if the discussion here about InterceptingFilter is following a similar "pattern" to the frequent questions about MVC on these forums, ie it is not providing an immediately clear and intuitive solution. Instead, it seems to be creating more questions than answers. That could be a fault of the pattern itself, how well it is explained, or maybe just part of the learning process.
    I think both. The Great Gurus are groping just as we are. Fowler gets his concepts mixed up and the J2EE patterns people tend to focus on paraphernalia and avoid clarifying the main issue.

    I think if Fowler had included the Intercepting Filter pattern in his book, we would have a better example to start with.

    But I find Captain Proton's example excellent. It helped me understand the pattern better.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  23. #98
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But I find Captain Proton's example excellent. It helped me understand the pattern better.
    The example was excellent, even though I understood the pattern easily enough, I hadn't seen an example as clear nor clean as that one

    On the Front Controller, Fowler suggests the use of the Front Controller with the Command pattern, but this is not a Front Controller requirement in it's self.

    Shame also, that Fowler didn't explain the Command pattern either, since he made a reference to it. Btw, wasn't the Command pattern given a spot on the ISA site prior to the books publication ?

    Think it was.

  24. #99
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    On the Front Controller, Fowler suggests the use of the Front Controller with the Command pattern, but this is not a Front Controller requirement in it's self.
    Perhaps not, but he states explicitly that the commands are part of the Controller.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #100
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    Finland
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have too played with MVC for a while, and I came up with this kind of idea.

    PHP Code:
    <?php
    abstract class JMVC_ActionController{
         
         public 
    $actions=array(); //Array of registered actions
        
    protected $model//Reference to model
        
    protected $view//Reference to View
        
    protected $requestPath
        
         public function 
    __construct($requestPath){
            
    $this->requestPath $requestPath;
            
    $this->initialize(); //Initialize before executing actions
                
    foreach($this->actions as $action){
                    if (isset(
    $_REQUEST[$action->getName()])) { //Execute requested actions
                        
    $action->execute(); 
                        
    $action->isExecuted() && $this->afterAction($action);
                    }
                }
            
    $this->main();
        }
        

    /**
     * JMVC_ActionController::initialize()
     * 
     * Initialize variables and register actions here.
     * 
     * @return 
     **/
        
    abstract protected function initialize();
    /**
     * JMVC_ActionController::afterAction()
     * 
     * Method is called each time when any of the registered actions is executed.
     * 
     * @return 
     **/
        
    protected function afterAction(Action $action){}
    /**
     * JMVC_ActionController::main()
     * 
     * Method is called after all requested actions are executed.
     * 
     * @return 
     **/
        
    abstract protected function main();
        
    /**
     * JMVC_ActionController::registerAction()
     * 
     * 
     * @return 
     **/    
        
    protected function registerAction($name,$methods){
            
    $methods is_array($methods) ? $methods : array($methods);
            
    $this->actions[$name]= new Action($name,$this,$methods);
        }
        
     
     }

     
     class 
    Action{
         public 
    $value '';
        public 
    $name '';
        private 
    $sender;
        private 
    $methods = array();
        private 
    $executed false;
        public 
    $error '';
        
         public function 
    __construct($name,JMVC_ActionController $sender,$methods){
            if (!
    method_exists($sender'action_'.$name)) {
                Throw new 
    Exception('Action method ('.$name.') not implemented at Class: '.get_class($sender));
            }
            
    $this->name $name;
            
    $this->methods $methods;
            
    $this->sender $sender;
        }
        
        public function 
    getName(){
            return 
    $this->name;
        }
        
        public function 
    getValue(){
            return 
    $this->value;
        }
        
        public function 
    isExecuted(){
            return 
    $this->executed;
        }
        
        public function 
    execute(){
            
    $value false;
            if (
    in_array('POST'$this->methods) && isset($_POST[$this->name])) {
                
    $value empty_val($_POST[$this->name.'_value']);
            }elseif (
    in_array('GET'$this->methods) && empty($value) && isset($_GET[$this->name])) {
                
    $value empty_val($_GET[$this->name]);
            }else{ 
                return;
            }
            try{
                
    $this->value $this->sender->{'action_'.$this->name}($value);
            }catch (
    Exception $e){
                if (
    $e instanceof ActionException) {
                    
    $this->error $e->getMessage();
                } 
            }
            
    $this->executed true;
        }
     
     }
    ?>
    And here's a very simple example.

    PHP Code:
    class Controller_example extends JMVC_ActionController{

        function 
    initialize(){
            
    $this->registerAction('add','GET');
            
    $this->registerAction('subtract','GET');
        }
            
        function 
    main(){
            
    $this->view = new View_example($this->model);
            
    $this->view->display($this->requestPath);
        }
        
        function 
    action_add($value=NULL){
            
    $this->model->value++;
        }
        
        function 
    action_subtract($value=NULL){
            
    $this->model->value--;
        }
    }


    Idea is that you have to make own methods to every action in the controller class. Now you can call the script like this: index.php?add (action_add method is called)
    index.php?subtract or (action_subtract is called)
    index.php?add&subtract (both methods are called)

    Basicly you can use extended ActionController class as front controller or page controller. So I'd just like to know what more expereinced OOP-gurus think about this. And please don't mind if my english is not very fluent, i type it so rarely. But I can read it very well


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
  •