Front Controllers, Page Controllers, Intercepting Filters

[HarryF]

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.

[codezilla]

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:

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:

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.

[codezilla]

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.

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.

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.

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).

[codezilla]

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.

[HarryF]

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.

[Selkirk]

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?

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.

[Selkirk]

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:

Web Server -----> Front Controller (Common Logic) ----> Action or Page Controller

Page Controller:

             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.

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.

[Selkirk]

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?)

[Selkirk]

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.

[Resolution]

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

[codezilla]

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.

[codezilla]

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.

[codezilla]

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.

[Resolution]

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

[codezilla]

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!

[codezilla]

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.

[HarryF]

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
// 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).

[JonR]

Hi,

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
include_once 'xxx-controller.php';
function afunction() {
  echo 'blah';
}
afunction();
?>

With an include in the controller:
xxx-controller.php

<?php
//... some stuff
include 'page.php';
exit(0);
?>

you get the redeclaration errors. With include_once in the controller:
xxx-controller.php

<?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

[Resolution]

Thank you for that explaination. I believe I have a grasp on the language being used - here goes.

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?

[codezilla]

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).

[codezilla]

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.

[codezilla]

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.

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.

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?

[mwmitchell]

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

[Dr Livingston]

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.

[JonR]

Hi,

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?

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:

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