The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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;

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.

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.

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.

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.

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.

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?

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.

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.

BTW, I think you can still have the equivalent of a "base class" in PHP using includes and procedural code.

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.

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

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.

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?

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.

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.

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

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.

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?

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";

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.

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?

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.

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:

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:

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.