| SitePoint Sponsor |
This is an excellent thread! A good part of it is still way above me, but going through a real life situation is really helping me start to get my head around it. Definitely some nifty things floating around here.
I attempted to run it, but is_a() is not defined. I must not have not have 4.2 installed on the server I am using. Maybe it wasn't meant to be run and is just a proof of concept. Either way, I like the code!Originally Posted by Resolution
codezilla, thank you for taking the time to respond. I realized there may of been a lot of questions!
Exactly what I wanted to know.Basically, I want to be able to easily apply pre-processing and post-processing logic to a simple script without relying on any Apache-specific mechanisms.I'm not talking about specific functionality using an enterprise level web application framework like WACT. I'm talking about general functionality in a typical PHP script.
I assumed this in the solve, we may be thinking alike here.I suppose that ideally post processing should occur for any filters that are higher up in the chain
This becomes a critical question after you posted 27 http://www.sitepointforums.com/showp...5&postcount=27.Quote: ResolutionIt won't work.
6. What happens if a class that's NOT a filter is included AS a filter?There are an infinite number of "what if" scenarios. What if you pass an array instead of an object? I'm not worried
How do you know if the filter being added is the correct TYPE or VERSION and not some other type or version?
If a non-filter object or the incorrect version or type of filter is passed to the Intercepting Filter the script could not olny cease to function but HANG the server. Imagine if you are on a shared server and this happens. The load balance spikes because the php hit some internal error and all the other people on the server suffer. Apache may even need to be reset. Which could mean your host might suspend privilages to scripting or even ban your account. Their time is their money. It could all happen if catch nets arn't in place.
This is also the reason I asked question 7.
My solution is a simple, put a check at the AddFilter() for the proper abstract class (filter) before it's added to the array of filters. This simple step could save you much greif and debug time later on when things get more complicated.
I've gotten Fowler's POEAA since that statement, please excuse my lack of description. By central connecting script I mean a central Front Controller that's going to do all the calling of the smaller/child controllers, ie Intercepting Filter, Application Controller and Template View. It's role would be to validate the incoming comands from the Page Controller or other Front Controller and then make sure that those general orders are carried out. It should be VERY thin, only enough to validate, and pass on commands.Then what do you mean by "central connecting php script"?
This seems out of scope based on you saying you want to keep it simple. Code morphing (to me) means having a script that is managed by another script. When conditions or requirments change the controling script will edit the (pagecontroller's)code. It's easier than it sounds. Think of a Template view that saves to file insted of echoing to screen and thats how I would do it.Quote: ResolutionGood point. Code morphing? What's that? Sounds complicated. I'm not sure how exactly I'm going to handle it. I'll probably either use a central config file, or do something per page.
10. Ie. Authentication or Pagecaching may not happen on EVERY page so how do you plan to expand on this idea when the site grows in size and Page Controllers? Code morphing?
As far as you design specifications, are you sure you want a Page Controller and a Template View meshed together?
Cheers
Andy,
yea, should of stated it would need the correct version for that to work. Just comment it out. It works.
PS: Thanks!
You're absolutely correct that my class needs some error handling. I leave it out of the code I post on sitepoint for two reasons: (1) it's ugly, (2) it makes the code harder to understand.This becomes a critical question after you posted post 27.
How do you know if the filter being added is the correct TYPE or VERSION and not some other type or version?
...
This is also the reason I asked question 7.
I think you're overestimating the severity of passing an invalid Filter to FilterChain. The script will probably generate a fatal error, but it certainly won't hang the webserver.
That's definitely a valid solution and I should probably incorporate it back into my own version. That's what I was originally attempting to do by extending a base InterceptingFilter class and using an is_a() test in FilterChain. I took it out since I decided against extending InterceptingFilter.
That's basically how I was thinking of all this from the beginning, but I've been persuaded that what I presented is base page controller, not a front controller. However, they're very similar concepts and are somewhat interchangable.
IMHO, "having a script that is managed by another script" is way more complicated than having a simple config file (I'm not talking about some crazy XML monster). But we're probably both misinterpretting what the other is thinking so I wouldn't get too hung up over this.This seems out of scope based on you saying you want to keep it simple. Code morphing (to me) means having a script that is managed by another script. When conditions or requirments change the controling script will edit the (pagecontroller's)code. It's easier than it sounds. Think of a Template view that saves to file insted of echoing to screen and thats how I would do it.
Definitely! I'm thinking of the most basic case like my original (slightly modified) example:
PHP Code:<?php include_once('basecontroller.inc.php'); ?>
<?php
include('UserDao.class.php');
$dao =& new UserDao();
$user =& $dao->find($_GET['id']);
if (! $user)
{
include('invalid_user.html');
exit;
}
?>
<html>
<head><title>User Info</title></head>
<body>
<h1><?=$user->getName()?></h1>
<p><?=$user->getProfile()?></p>
</body>
</html>
Anyone ever decide if the 'exit()' thing was a bad thing? I'm using this same idea in a project, and i like it. I'm not sure if I can see what's wrong with it. Isn't php exiting anyway when the script is done?
Matt
I believe you have been too quick to discard a centralized script (a FrontController). A typical FrontController will pass control to one of the actions, and will employ complex logic and a central configuration file to make the decision. But the latter is not a requirement.
Consider a dumb FrontController which, given the url http://server/index.php/gallery/edit, simply includes gallery/edit.php (relative to some predefined directory).
The discussion here revolves around including (transparently) PageController code in naive scripts. How about the other way round - including these naive scripts (again, transparently) from a FrontController?
What you gain is the ability to easily add support for filters etc without and prepend/append tricks. What you lose is a... well, what? With this dumb FrontController you don't have a performance hit. The only issue is whether it can be truly transparent.
So I am wondering: if your script (gallery/edit.php) is included from a centralized one instead of being simply run by Apache, does it make a difference for the script? And if it does, can it be easily fixed?
For example, $_SERVER['SCRIPT_NAME'] would be incorrect, but that can be fixed. So, if it turns out there are no differences for the script, then what's the disadvantage of a centralized FrontController?
My (currently under development framework is set up) very much like that. It combines some of the ideas of the FrontController with the PageController pattern, much like you describe. Instead of simply including a PHP script, that script is 'wrapped' into a PageController class (the C in MVC).
It gives you all the advantages that you mentioned in your post, without any disadvantages that I can think of.
Well Captain, we'll be waiting for that code t show up
( or at least, me ).
And me too!Well Captain, we'll be waiting for that code t show up
( or at least, me ).
Matt
I don't really like the FilterChain and addFilter($filter)-command writing (just my personal feelings about it ;)). I have come up with the code below. I tried to follow the Decorator-pattern followed very strictly.
The abstract Component is the class Controller:
The abstract Decorator is the class Filter:PHP Code:// abstract Component in the Decorator-pattern
class Controller
{
var $request;
var $response;
function Controller(&$request, &$response)
{
$this->request =& $request;
$this->response =& $response;
}
function process() {}
}
Then I have the class FrontController which is a concrete Component:PHP Code:// abstract Decorator in the Decorator-pattern
class Filter extends Controller
{
var $filter;
function Filter(&$filter)
{
$this->filter =& $filter;
$this->request =& $this->filter->request;
$this->response =& $this->filter->response;
}
function process()
{
$this->postProcess();
$this->filter->process();
$this->preProcess();
}
function postProcess()
{
}
function preProcess()
{
}
}
The FrontController calls a command (a PageController) which in it self is also a concrete Component. A example is the class NoCommand (but every command(\PageController) is build like this:PHP Code:// concrete Component in the Decorator-pattern
class FrontController extends Controller
{
function FrontController(&$request, &$response)
{
parent::Controller($request, $response);
}
function process()
{
$command =& $this->getCommand($this->request, $this->response);
$command->process();
}
// can also be used whithout initiating a FrontController. If not needed then change
function &getCommand(&$request, &$response)
{
$commandClassName =& $this->getCommandClass($request);
return new $commandClassName($request, $response);
}
// can also be used whithout initiating a FrontController. If not needed then change
function getCommandClass(&$request)
{
$commandClassName = ($request->getParameter('command'))
? $request->getParameter('command').'Command'
: 'NoCommand';
if (file_exists(PATH_CONTROLLER.$commandClassName.'.php'))
{
include_once(PATH_CONTROLLER.$commandClassName.'.php');
return $commandClassName;
}
else
{
trigger_error($commandClassName.'.php doesn\'t exist!', E_USER_ERROR);
}
}
}
A Filter (a Concrecte Decorator) is constructed like this:PHP Code:// concrete Component in the Decorator-pattern
class NoCommand extends Controller
{
function NoCommand(&$request, &$response)
{
parent::Controller($request, $response);
}
function process()
{
echo "<p>NoCommand:process</p>\n";
}
}
or like this:PHP Code:// concrete Decorator in the Decorator-pattern
class AuthFilter extends Filter
{
function AuthFilter (&$filter)
{
parent::Filter($filter);
}
function process()
{
parent::process();
}
function postProcess()
{
echo "<p>AuthFilter:post</p>\n";
}
function preProcess()
{
echo "<p>AuthFilter:pre</p>\n";
}
}
I would use it like this:PHP Code:// concrete Decorator in the Decorator-pattern
class TimingFilter extends Filter
{
var $start_time;
function TimingFilter(&$filter)
{
parent::Filter($filter);
}
function process()
{
parent::process();
}
function postProcess()
{
$this->start_time = $this->getMicroTime();
echo "<p>TimingFilter:post ".($this->getMicroTime()- $this->start_time)."sec</p>\n";
}
function preProcess()
{
echo "<p>TimingFilter:pre ".($this->getMicroTime()- $this->start_time)."sec</p>\n";
}
function getMicroTime()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
}
When I need a Filter I would do this (and if need more I would nest more):PHP Code:$request =& new HttpRequest;
$response =& new HttpResponse;
$application =& new FrontController($request, $response);
$application->process();
or change the getCommand-method in the FrontController, like:PHP Code:$request =& new HttpRequest;
$response =& new HttpResponse;
$application =& new TimingFilter(new AuthFilter(new FrontController($request, $response)));
$application->process();
If I don't need a FrontController and want to use a Command(\PageController) directly, I can use it the same way:PHP Code:function &getCommand(&$request, &$response)
{
$commandClassName =& new TimingFilter(new AuthFilter($this->getCommandClass($request)));
return new $commandClassName($request, $response);
}
Do you think this to be a good way? Are I making some big errors? One thing is that if you want to put Filters dynamicly based on a configuration, then addFilter($filter) is easier, like:PHP Code:$request =& new HttpRequest;
$response =& new HttpResponse;
$application =& new TimingFilter(new AuthFilter(new NoCommand($request, $response)));
$application->process();
-RémyPHP Code:foreach($filters as $filter)
{
$fc->addFilter($filter);
}
I've finally managed to read this entire thread (while watching an Indiana Jones movie to get twice the entertainment). So now I hope I can say something intelligent.
I'm not sure I fully understand what you mean, but "wading through a massive switch statement" seems clear enough. I clocked a switch statement with 100 cases and it seems to take about 40 microseconds. That's negligible compared to processing templates and the like.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
I was so sure I knew exactly what the difference between a Page Controller and a Front Controller was. After this discussion I'm less sure. My provisional conclusion is that the only substantial difference is that a Front Controller is capable of handling commands or actions more flexibly. It can:
- Perform several actions in sequence if necessary
- Handle interactions between actions (whatever that means)
- Let you keep several actions in one file or class (this is what I've called the Command Group pattern)
Apart from that, they don't seem to satisfy different requirements, which means that most if not all of Fowler's attempts to distinguish them are based on misunderstandings.
Would anyone care to agree or disagree with this?
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
I've always understood it to be more simple than that even. Doesn't it only perfom a single action (getting the REQUESTED action or command)? I've always thought that once it does that, it stops doing anything, so as not to handle interactions between actions. Really just the REQUEST gatekeeper.
One thing that has me confused is how, when and where would you actually have the request (url or form) call more than one action? I've never seen a url like: ?action1=doThis&action2=doThat . Seems to me that this only complicates things and that the actions themselves would implement multiple action calls.
Unless the current action gets that info from the url, and then calls that action while executing itself (which in itself is another FrontController). But using the main FrontController (index.php) there, to actually manage multiple actions doesn't seem practical. How do the multiple REQUEST actions interact when being called from the main FrontController?
Matt
In Fusebox (the framework I use - which is a FrontController), you pass a single request into the Fusebox.
i.e.
However, while in the Fusebox, as it is running you can perform more requests as needed.Code:index.php?fuseaction=news.listHeadlines
I can place as may of these module calls as needed inside whatever current fuseaction is being executed.PHP Code://suppresslayout prevents a recursive template load
Fusebox::module(array('fuseaction'=>'page.showFooter','suppressLayout'=>true));
The point here I guess in relation to the quote above is that while, in Fusebox you don't pass multiple actions in via the URL, you can chain call them from inside a Fuseaction. Indeed in a forum application I am writing right now, I do that to create certain parts of the forum layout.
Fusebox also allows me to break an application into sub-circuits (sub-components if you will)... So you don't necessarily end up with a massive switch with 100 cases. The forum I am writing is broken up into three sub-circuits at the moment, and each switch has ~20 options.PHP Code:case 'viewTopic':
if($privs->view((int)$_GET['f'])){
$Fusebox['pageTitle']='View Topic';
$XFA['deletePost']=$Fusebox['thisCircuit'].'.deletePost';
$XFA['editPost']=$Fusebox['thisCircuit'].'.editPost';
$XFA['replyPost']=$Fusebox['thisCircuit'].'.replyPost';
FuseForum::module(array('fuseaction'=>'forum.replyLinkSection','suppressLayout'=>true));
include('act_viewThread.php');
include("dsp_viewTopic.php");
FuseForum::module(array('fuseaction'=>'forum.replyLinkSection','suppressLayout'=>true));
}else{
FuseForum::module(array('fuseaction'=>'forum.privsError','suppressLayout'=>true));
}
break;
Cheers,
Keith.
I still don't think any of this solves the most basic of use cases:
- How do I integrate something in to any framework
Harry sites the case of integrating phpBB with his ezPublish. Anyone who has worked with these frameworks go to pain staking tasks to perfectly object orient the framework (just like this thread is trying to accomplish), but it still doesn't solve the question:
I have this great framework, classes all well encapsulating their tasks, but how in the world do I apply that at an integration level? You would almost have to re-write (or significantly modify) any of these other scripts. Do you really want to re-write forum code? I think not...
Why, my original post was tackling this very issue: whether you can use naive scripts (for example, phpBB) with a simple FrontController.
You're right. You've summed it up very well. I was being too creative too late in the evening. I was trying to dream something up which would be a clear advantage of using a Front Controller. But Front Controllers as generally defined are too dumb to do what I suggested and probably should be.
So I'm left with just the last of my points: A front controller allows you to group several actions together in one file or one class. (See this thread.)
I think it's a good idea, but it's not what Fowler is advocating.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
The way I've solved similar integration problems (though probably smaller ones) is by having two controllers at work at the same time in the same script. Let the script you're trying to integrate do whatever it usually does to generate and interpret HTTP requests. Then add your own controller and make sure it knows what requests to handle, by marking the requests or by some other kind of logic.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
If the tools to integrate are also based on some MVC-pattern then they could be integrate easily.
If phpBB has this separation (never looked a there code) then you could throw away the controllers and views of phpBB and use the models in your one framework!
(If this isn't done then a class would need to be written that uses the Facade-pattern, if this is possible with phpBB.)
-Rémy
I was re-reading this thread when I found this comment, and I can't fully understand what's going on without knowing what these "notions" are. Can you or Selkirk provide a pointer or URL to them? All I've found is an essentially empty document on the WACT Wiki.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
dagfinn,
I think it was this thread:
http://www.sitepoint.com/forums/showthread.php?t=111555
In particular post #22
Per
Everything works on a PowerPoint slide
Codezilla -
Thanks for posting your script - post #1
I've just tried it out and well happy that it works, though can I ask a few questions ?
1) You have each filter extend to the Intercepting Filter. Looking now, at the pattern - link provided by Harry on his site leading to objectmonkey - and then at your script I cannot understand why the need to extend to the InterceptingFilter class ?
The class method Run() isn't executedIs it an Abstract method by any chance.
Could you safely do without this class altogether w/out breaking the Pattern ?
2) How'd for example, you work a View Layer into the Intercepting Filter Pattern, or maybe that should be the other way around - not sure.
I'm looking at the Composite View pattern just now as well, I believe I have something just now that could represent this pattern, but I need to look more at the pattern again.
I'm just looking to clear these points up, so anyone care to help me out ?
Thanks.
Yes! InterceptingFilter is not strictly necessary. It's really just an abstract class that (theoretically) describes how its subclasses should work. The idea (in this case) is that all subclasses of InterceptingFilter should have a run() method.
When the FilterChain object is process()'d it calls the run() method of all the registered filters (refer to the code from frontcontroller.inc.php).The class method Run() isn't executed
The way I'm handling it, the last filter to be executed (PageControllerFilter in my example) does an include() on the requested page (using $_SERVER['PATH_TRANSLATED']). That page, let's call it index.php, contains all your control and view logic (which can be plain old procedural PHP if you want).
That's just my approach -- it works well for my needs. Many people handle it very differently.
Thanks for taking the time to clear these things up for me
At the moment the View is of a Composite View, which proberly could do with some more work on it, so I'll see what I can do with that and the Front Controller.
Thanks again
After all the recent dicussions on Front and Page Controllers, I think I'll just *bump* this thread, since I've come across it in a search
Posting Permissions
Bookmarks