SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 100
  1. #26
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    The current WACT template implementation does not require a deployment phase because the templates are compiled automatically on demand. Could a code generation technique applied to front controllers & intercepting filters also avoid requiring a Deployment Phase?
    Think it can be done automatically (fully automatic on Apache by using the 404 trick).

    For a page controller which hasn't actually been deployed yet, this might happen;

    1. User requests http://www.example.com/example_page.php

    2. Apache finds page doesn't exist, calls 404 hander deployer.php

    3. deployer.php copies /home/username/deploy/example_page.php to /home/username/www/example_page.php (adding necessary mods for front controller)

    4. Page is served

    5. User requests http://www.example.com/example_page.php again.

    6. example_page.php (or some included code) checks the modification time on /home/username/deploy/example_page.php and compares with itself - updates if needed.

    8. Latest version is executed

    9. Page is served

    Something like that. For users unable to modify their server's 404 handler, the initial deployment would need to be manually invoked but after that, no problem.

    Whether this is a good idea though, not sure. Some things that might be problematic;

    Confusing to develop with - you place your script in a different directory to the one it will actually be executed from - might make includes etc. mind boggling.

    Easy to break(?). A script which "updates itself" may not be a pretty thing.

  2. #27
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    One thing, though. I would hate to see filter classes being included and instantiated, but never called. Seems like a waste.
    Good point (again)! Here's a modification to FilterChain:

    PHP Code:
    class FilterChain
    {
        var 
    $filters = array();

        function 
    FilterChain()
        {
        }
        
        function 
    register($filterClass)
        {
            
    $this->filters[] = $filterClass;
        }
        
        function 
    execute()
        {
            
    reset($this->filters);
            
    $this->next();
        }

        function 
    next()
        {
            if (
    $filterClass current($this->filters))
            {
                
    next($this->filters);
                include_once(
    'filters/' $filterClass '.class.php');
                
    $filter =& new $fcfilterClass);
                
    $filter->run($this);
            }
        }
        

    This would change frontcontroller.inc.php to:

    PHP Code:
    require_once('FilterChain.class.php');
    $fc =& new FilterChain();
    $fc->register('OutputBufferingFilter');
    $fc->register('TimingFilter');
    $fc->register('RequestDispatchingFilter');
    $fc->execute();
    exit; 
    There are two obvious problems though:

    1. I'm making assumptions about the location and naming of the filters.
    2. There's no way to pass parameters to the Filter constructors.

    Any suggestions? As always, I want to keep things as absolutely simple as possible.

  3. #28
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    How about some guesses at requirements for how intercepting filtes / controllers should work in PHP?

    ...
    Harry, I like the rules you came up with. In fact, they are all design requirements that I imposed on the solution I came up with.

    Quote Originally Posted by HarryF
    An alternative approach may be to wrap the example_page.php in a function which is called from PageController but if this needs to be hard coded into example_page.php, it's already violating point #3 above. Not sure...
    I like what you trying to do, but I don't like the added complexity it creates. Personally, I'd rather have one naughty exit() call, than require that every page is wrapped inside a function.

    Quote Originally Posted by HarryF
    If example_page.php is placed somewhere outside of the web root, for example, then "deployed" into the web root with some script which can either be manually executed by a developer or the Apache 404 trick.
    Again, for my needs at least, I think this creates unnecessary complexity. Plus it violates your rule #4.

    Quote Originally Posted by HarryF
    What if the page controllers in their "pre-deployed" state are required to have an associated unit test of some sort? They are only "deployed" if the test passes.
    Unit testing is something I'd certainly like to explore more, but I'm a bit intimated by it all (probably with poor reason).

  4. #29
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Could a code generation technique applied to front controllers & intercepting filters also avoid requiring a Deployment Phase? Without contradicting the "naive application logic" model that codezilla seems to be pursuing?
    Pardon my ignorance, but what's the big deal about deployment -- why the need for code generation? I'm not sure what exactly you mean by "naive application logic" but maybe it's related to my aforementioned lack of knowledge. My primary design goal is simplicity, but hopefully it's not at the expense of efficacy.

  5. #30
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Harry, I like the rules you came up with. In fact, they are all design requirements that I imposed on the solution I came up with.
    There's probably some more but like your approach as well. Need to ponder the exit() factor some more - perhaps it's not an issue.

    I like what you trying to do, but I don't like the added complexity it creates. Personally, I'd rather have one naughty exit() call, than require that every page is wrapped inside a function.
    Likewise thinking it's too much. On the one hand, as far as I can see, think it manages to remain independent of any particular "style" of page controller. On the other, think it's going to be confusing to use plus makes it harder to do things that work well right now.

    Unit testing is something I'd certainly like to explore more
    Simple Test. If you've got time to read, the documentation is excellent (some on website, some more with download), discussing both theory and practice.

  6. #31
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by codezilla
    I don't require its use. In fact, it is one of my design requirements that I don't use auto_prepend_file, or any other Apache-specific functionality -- which is why I used include().
    If you don't use auto_prepend_file, how do you avoid Cannot redeclare errors from functions and classes in the "include back" file?

    Quote Originally Posted by codezilla
    In your opinion, would it still be bad to have exit; in frontcontroller.inc.php if it were called using the auto_prepend_file mechanism instead of include()'ing it at the top of every page, disregarding the option of using auto_append_file?
    Its a bit tricky. It also depends on having ini file access (or .htaccess overriding.) I'll have to think more about it.

  7. #32
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by codezilla
    Good point. As I see it (and should have said it) my frontcontroller.inc.php also contains all the code common to the application: require()s, include()s, define()s, ini_set()s, and whatever else is needed. I personally don't like the index.php/module/page mechanism; however, I was trying to accomplish a similar objective in a different way. Anything that normally goes in your index.php (which is a front controller) could instead go in the include()'d frontcontroller.inc.php.
    Yeah, I consider that to the be page controller base class pattern, not the Front Controller pattern. I haven't yet gotten to the Page Controller page on the WACT wiki to explain this.

    Front Controller:
    Code:
    Web Server -----> Front Controller (Common Logic) ----> Action or Page Controller
    Page Controller:
    Code:
                 Page Controller Base Class (Common Logic)
                              ^
                              | (inherits)
                              |
    Web Server -------> Page Controller -----> Action
    BTW, I think you can still have the equivalent of a "base class" in PHP using includes and procedural code.

    Quote Originally Posted by codezilla
    The reason I still consider my example to be a front controller is because it does do dispatching, or at least what I consider (possibly incorrectly) to be dispatching.
    Since it dispatches to only one possible action when directly included in the file, I guess I would call it a page controller. Perhaps when it is in the auto_prepend_file, it could be called a page controller. Its all very confusing isn't it.

  8. #33
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by codezilla
    PHP Code:
    class InterceptingFilter
    {

        function 
    InterceptingFilter()
        {
        }
        
        function 
    run(&$filterChain)
        {
            
    $filterChain->process();
        }
        

    I'm not a big fan of these do nothing base classes. I think they harm reusability in the long run, although I am told they are good for documentation. (None of the filters inheriting from this class actually call parent::run, do they?)

  9. #34
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by codezilla
    Pardon my ignorance, but what's the big deal about deployment -- why the need for code generation?
    complicated deployment sucks. -- Some of the discussion on implementing intercepting filters in WACT is occurring here. Code generation is one possible option.

    I'm not sure what exactly you mean by "naive application logic" but maybe it's related to my aforementioned lack of knowledge.
    No. I mean that the code that is having a filter applied to it is not designed to be filter aware. You are not applying any constraints to the application logic, such as requiring a specific code structure or specific filtering calls. (The common include barely counts.) I think this is a good thing.

  10. #35
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey,

    I read this post then went to Harry's site and read his article on Front Controllers, then went to Java web site and read theirs and STILL I'm trying to figure out what PROBLEM you all are tring to solve?

    I've been designing them for years and didn;t know they were called that, I just used the LOGIC to guide me through development pits until things worked flawlessly. When I'm developing I don't use ANY code. I just use flow chart patterns until the logic gets me to where I want to be.

    Could you all represent this problem as a flowchart or UML diagram for those of us who are doing some head scratching but would like to participate in the conversation - even if it's just listening real good?

    cheers

  11. #36
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    If you don't use auto_prepend_file, how do you avoid Cannot redeclare errors from functions and classes in the "include back" file?
    I should have said, "which is why I use include_once()". I've never got a Cannot redeclare, so it's just a guess, but I assume using include/require_once() gets around that.

  12. #37
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Since it dispatches to only one possible action when directly included in the file, I guess I would call it a page controller. Perhaps when it is in the auto_prepend_file, it could be called a page controller. Its all very confusing isn't it.
    I may be misinterpretting it, but I'm basing my definition on the one Fowler gives in PoEAA, "A controller that handles all requests for a Web site". Granted, it only handles requests for pages that include_once() it, so I can see why this could also be thought of as a base page controller. I agree that using the auto_prepend_file mechanism would be a more pure interpretation of Fowler's definition (I'm assuming you meant front controller, not page controller), but I consider them to be bascially the same thing -- as long as one has enough self-discipline to put include_once('frontcontroller.inc.php') at the top of every page.

  13. #38
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    I'm not a big fan of these do nothing base classes. I think they harm reusability in the long run, although I am told they are good for documentation. (None of the filters inheriting from this class actually call parent::run, do they?)
    Yeah, I agree. I recently re-read the thread where you and Vincent discussed this. You sold me. In my initial FilterChain example (Post #1) I had it check to make sure each filter instance is_a FilterChain, but in retrospect that was clearly a big fat waste. I fixed that in my updated FilterChain (Post #27). I also commented out extends InterceptingFilter in each filter class on my development machine.

  14. #39
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I agree that using the auto_prepend_file mechanism would be a more pure interpretation of Fowler's definition (I'm assuming you meant front controller, not page controller), but I consider them to be bascially the same thing -- as long as one has enough self-discipline to put include_once('frontcontroller.inc.php') at the top of every page.
    Then again one could create a required base class with auto_prepend_file in the class constructor. At least that's what I do.

    cheers

    Next day: I didn't realize they ment the APACHE auto_prepend_file. In which case I agree with the quote. ?? I must of been sleepy
    Last edited by Resolution; Nov 12, 2003 at 21:26.

  15. #40
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    No. I mean that the code that is having a filter applied to it is not designed to be filter aware. You are not applying any constraints to the application logic, such as requiring a specific code structure or specific filtering calls. (The common include barely counts.) I think this is a good thing.
    Okay, cool! 'Cause I wouldn't have it any other way!

  16. #41
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Resolution
    Could you all represent this problem as a flowchart or UML diagram for those of us who are doing some head scratching but would like to participate in the conversation - even if it's just listening real good?
    These are the two main resources that I used:

    Core J2EE Patterns: Intercepting Filter [sun.com]
    Enterprise Solution Patterns: Intercepting Filter [microsoft.com]

    They both have several charts that explain things better than I can.

  17. #42
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Could you all represent this problem as a flowchart or UML diagram for those of us who are doing some head scratching but would like to participate in the conversation - even if it's just listening real good?
    Essentially this is a very simple problem which quickly becomes confusing both with "alien" terminology like Front Controller and Intercepting Filter, as well as the "boundaries" being blurred by what PHP actually is, as a technology.

    The basic problem is how do we centralize some logic (e.g. logging, authentication) without requiring all PHP scripts be included by some central PHP script.

    My fundamental opinion is Apache itself is the Front Controller when working with PHP, as opposed to a Java Servlet, where you'd implement a Front Controller with Java itself.

    When an HTTP request comes into a Java Servlet, the servlet needs to select which code gets executed next.

    When an HTTP request comes into Apache + PHP, Apache effectively selects the PHP script to execute for you (if one exists for the requested URL). That makes life easier, on the one hand - simply add a new script somewhere under the web root and you can immediately begin accepting requests, the script being termed a "Page Controller" (or perhaps an Application Controller in some circumstances - but that's a diversion right now). The downside is how do you "attach" the central logic that must be executed for every page (e.g. logging / authentication / timing), without having to make significant modifications (ideally no modifications) to the script?

    There are many approaches which have been used in PHP to date (some re-implementing the front controller in PHP) but, IMO, we don't have the "perfect" solution yet; one that will suit everyone, irrespective to coding style. As a result, most PHP frameworks have a fairly short lifespan and you tend to get frustrated users (like this - "Yet Another Framework").

    Been thinking about those requirements again. There may be a boiled down version which goes something like;

    "Does not require implementing 404 pages in PHP"

    That's a little confusing given I was talking about that Apache 404 trick earlier (a special case which is an exception) but what I really mean is I think this is "bad";

    PHP Code:
    <?php
    // index.php

    switch ( @$GET['module'] ) {
        case 
    'news':
            include 
    'news.php';
        break;
        case 
    'forum':
            include 
    'forum.php';
        break;
        default:
            
    header('http/1.1 404 Not Found');
            die(
    'Page not found');
        break;
    }
    ?>
    The above is attempting to be a Front Controller (IMO) but would be better left to Apache (ditch the above and simply let people access news.php or forum.php directly).

  18. #43
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Watford, UK
    Posts
    62
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by codezilla
    I may be misinterpretting it, but I'm basing my definition on the one Fowler gives in PoEAA, "A controller that handles all requests for a Web site". Granted, it only handles requests for pages that include_once() it, so I can see why this could also be thought of as a base page controller.
    I go with the base page controller description - the implementation has some similarities with Fowler's PoEAA Page Controller example: Page Handler with a Code Behind (C#) (340).

    Re. the redeclaration thing - I can't see how include_once gets round the issue, if you define functions or classes in the page controller, e.g.

    page.php
    PHP Code:
    <?php
    include_once 'xxx-controller.php';
    function 
    afunction() {
      echo 
    'blah';
    }
    afunction();
    ?>
    With an include in the controller:
    xxx-controller.php
    PHP Code:
    <?php
    //... some stuff
    include 'page.php';
    exit(
    0);
    ?>
    you get the redeclaration errors. With include_once in the controller:
    xxx-controller.php
    PHP Code:
    <?php
    // ... some stuff
    include_once 'page.php';
    exit(
    0);
    ?>
    you don't get anything. mwmitchell got round the problem right at the beginning of the thread, but I can't see a more generic method at the moment.

    I'm seeing your example page controller more as a template than a controller (I know you said that it combines controller and view ).

    I'm liking the idea of some kind of Layer Supertype Page Controller providing a Template Method run/execute/process... + intercepting filter setup. Page Controllers under the web root inherit from this, templates are kept wherever and brought in by the controller when required. This obviously loses the simplicity and the easy application of the filters to other peoples code libraries tho - but I can't see how this can be reliable anyway with the redeclaration issue?

    Cheers,

    Jon

  19. #44
    SitePoint Zealot
    Join Date
    Feb 2003
    Location
    Virginia
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you for that explaination. I believe I have a grasp on the language being used - here goes.

    Quote Originally Posted by HarryF
    The basic problem is how do we centralize some logic (e.g. logging, authentication) without requiring all PHP scripts be included by some central PHP script
    Question is, why are you tring to tackle this puzzle without a central connecting php script?

  20. #45
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by JonR
    Re. the redeclaration thing - I can't see how include_once gets round the issue, if you define functions or classes in the page controller, e.g.
    Ah, I see. I never declare functions or classes in my main script.

    I'm seeing your example page controller more as a template than a controller (I know you said that it combines controller and view ).
    It doesn't look much like a page controller, because there isn't much controller logic being executed, but that was to keep the example simple.

    My vision is that a PHP block appears at the top of the page containing all the page controller logic and below it is a TemplateView mixing HTML and presentation logic (PHP).

  21. #46
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Resolution
    Question is, why are you tring to tackle this puzzle without a central connecting php script?
    Personally, I feel that forcing everything through a single file (e.g. /index.php/extra/parameters) is unnecessarily complicated. I think it's much simpler (and therefore better for my purposes) to let each "atom" of functionality be its own page (generally speaking). Using a single script may be more powerful in many situations, but for the projects I work on, I need the flexibility and simplicity to have each page stand on its own. I've tried it both ways and find the page-centric version much easier to build and maintain.

  22. #47
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Yeah, I consider that to the be page controller base class pattern, not the Front Controller pattern. I haven't yet gotten to the Page Controller page on the WACT wiki to explain this.
    Quote Originally Posted by HarryF
    My fundamental opinion is Apache itself is the Front Controller when working with PHP, as opposed to a Java Servlet, where you'd implement a Front Controller with Java itself.
    Quote Originally Posted by JonR
    I go with the base page controller description - the implementation has some similarities with Fowler's PoEAA Page Controller example: Page Handler with a Code Behind (C#) (340).
    Okay, okay! You guys have convinced me! My frontcontroller.inc.php is not a Front Controller, but a Base (Page) Controller (or at least a draft of a proper one).

    I think I was thrown off because Intercepting Filters are usually mentioned in the context of Front Controllers, but there's certainly no reason why they can't be used with Page Controllers.

    So, where does that leave my code? I'll rename frontcontroller.inc.php to basecontroller.inc.php, but are there other changes that are needed? Rename FilterChain to FilterManager? Anything else?

  23. #48
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If you had a Request class (handles all POST and GET), would you consider that a filter also? In a framework like this, would it be OK to consider all classes being used (part of the core framework) as a InterceptingFilter class?

    Also, would it be a problem if all InterceptingFilters had access to the filter manager? like:

    $filterManager =& $this->fm;

    That way you could access an InterceptingFilter previously loaded.

    Thanks,

    Matt

  24. #49
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A bit late in replying though I also had the feeling that you were refering to a Page Controller myself from this bit...

    ...find the page-centric version much easier to build and maintain.

  25. #50
    SitePoint Enthusiast
    Join Date
    Aug 2003
    Location
    Watford, UK
    Posts
    62
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by codezilla
    Ah, I see. I never declare functions or classes in my main script.
    Fair enough . I'm curious as to why you stress that point?

    Quote Originally Posted by codezilla
    My vision is that a PHP block appears at the top of the page containing all the page controller logic and below it is a TemplateView mixing HTML and presentation logic (PHP).
    Thats cool, personally I think I prefer to require in the relevant templates from elsewhere based on the controller logic. It's horses for courses tho, maybe that's unnecessarily complicating it. It doesn't really affect the main issue here:

    Quote Originally Posted by codezilla
    Intercepting Filters are usually mentioned in the context of Front Controllers, but there's certainly no reason why they can't be used with Page Controllers.
    Nicely put! Your method is very nifty, whatever the names of the classes.

    Cheers,

    Jon


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
  •