Thanks, I'm honored! :)
Excellent post Captain Proton. You are now the author of an important and featured thread
The base InterceptingFilter class would contain a constructor that accepts a 'target' filter, the $nextFilter in the examples above. It also has a processRequest() method that does nothing but call the $nextFilter's processRequest() method: in other words, it passes on the request to the next filter in the chain.
If you have multiple sections of your website/application that need a different series of filters, the easiest way is to simply have more than one FrontController and let each one set up its own filter chain.
In the quote above, different scenarios are laid out where different filters would need to run depending on the page/section requirements. How are you configuring what should be in the FilterChain?
The guys at sun would :) [url=http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html[/url]
I dont know the term "View Helper" but I wouldnt put business logic in a class that specificly relates to the view
My apologies to you and to Brenden Vickery. You are right, I have mixed up a J2EE pattern with Martin Fowler's book.
Though if I do remember, after reading the book several times, M Fowler does talk about a helper and it isn't the View Helper Pattern either
I think that Intercepting Filters help you to view the clear distinction between a) the code that do the actual work for the task that a user wants to accomplish (the PageControllers) from b) those that carry out the 'boring' and distracting-from-the-main-concern stuff (the InterceptingFilters). But I have grown used to have my code structured like that so can't say that I'm totally unbiased.
Using intercepting filters to carry out non-client tasks has never felt quite right to me. I think it arbitrarily over-emphasises client output in the design - just one of a series of actions.
Very good question :) That's the great thing about Intercepting Filters. They have the power to 'intercept' the request and do something else with it. In the case of authentication, the AuthenticationFilter can stop the request from being processed by the PageController by simply not passing it on to the next filter in the chain. Here is the code from my AuthenticationFilter base class. It's the "skeleton logic" for authentication, where subclasses can fill in the "rest of the body" so to speak.
In your earlier example the Front Controller is the last item in the filter chain and the location where the page controller is initialized. Also, the Authorization filter example stops the chain if authorization fails and therefore it never reaches the Front Controller and a Page Controller is never selected... and I'm sure you can see where this is going.
So, if the Intercepting Controller is not supposed to notify anything else in the chain as to what happened, how do I tell my Front Controller that authorization failed and it needs to load the AuthorizationFailedController?
I think the code is kind of self explaning, but feel free to ask questions of course is anything is not clear.
function processRequest(HTTPRequest $request, HTTPResponse $response)
$pageController = $this->getAuthenticationPageController($request, $response);
$view = $pageController->getView();