| SitePoint Sponsor |
harry fuecks does a good job at explaining mvc. so if you didn't already, go on and read it.
http://www.phppatterns.com/index.php...leview/19/1/1/
you won't see a lot of explanation on the model in theese mvc-discussions. that's because it's really outside the scope of mvc. basically mvc is about control-flow in your application.
about modrewrite : http://www.sitepoint.com/article/910/
I took a look at your code and I tend to like this implementation. It seems quite straightforward to me. I assume that I can also do the following if I am using PageControllers rather than a FrontController?Originally Posted by mwmitchell
This way I can add different filters to the chain depending on the requirements of the request (eg. secured area, regionalised, language, etc.)PHP Code:// view-events.php
require_once( 'FilterManager.php' );
require_once( 'Authenticate.php' );
$fm =& new FilterManager();
$fm->setController( new ViewEventsController() );
$fm->addFilter( new Authenticate.php );
class ViewEventsController() {
function ViewEventsController() {}
function execute() {}
}
What would be the drawbacks of this? (besides the obvious duplication of some minimal code).
Cheers,
Af.
well, that'll be the hole point of using frontcontroller vs. pagecontroller. the frontcontrollers sole purpose is to centralize that kind of logic.
Would this be the quote you're referring to ?
All he says in that, is that you will have a single point where you can translate the rewritte url, instead of doing it in each pagecontroller. he doesn't imply that you needn't use modrewrite.
I somehow missed that post of yours. If you wind back 5 posts, you'd see me posting this :
So definately some decoration going on here i suppose ?
As far as i get it, the Decorator pattern is a very generic pattern, were the InterceptingFilter is more specific to a given problem area (I think it's solely used in relation to the MVC-pattern).
I would imagine that it's the job of a Front Controller it's self to select and mange a language to use ? To decide on a given page is private or not ?eg. secured area, regionalised, language, etc.
This isn't the intentions of the Intercepting Filter as I see it
Also, you have piped a Page Controller directly to the Intercepting Filters, though is this viable ? Are you intending to add all possible Page Controllers to your Filters now ?
Besides, you'd need to Authenticate prior to execution of a Controller anyways, not the other way around as in your example
Though I do appreciate that you are new to this level of discussion, I'm in a forgiving mood today
Anyways, hope I'm of some help to you anyway, if you've any questions either post at this thread, or just PM me and I'll try to help if I can
Captain,
A while back in this thread you stated that Mojavi wasn't a true Front Controller implemnetation. I was hoping you would spend some time elaborating on that statement.
Thanks,
JT
ok, there was a bit of discussion before on extending a controller from a filter class..is this ok? in the script I'm making the way everything is put together, this is almost th eonly way to have it work ok. I borrowed
Basically I think I'll have it like this: the required data, just the info from $_GET will go through all the filters, then finally get to the front controller. After it gets there the front controller will choose one of the page controllers (or whatever you want to call them...they are page specific though so..), and call that. Then that will choose the specific command it needs to execute, which will get all required data and then the view iwll be selected. And that's about all. the reason I want it like this is because there are basically two parts to my application, and each of these two parts have different actions that can be done under them. For instance there is a part to modify and view the information added; and so under that part you can add, edit, delete, and view the information. the other section is to add / delete users.
The FrontController is the application's sole access point to the outside world. This receives user input and would initiate a filter chain (if you're using one) rather than a FrontController being loaded by a filter chain.
Actually I wish I had the time to write up a "J'Accuse Intercepting Filters" piece but it would have to be long and detailed. Still, don't let me put you off. I'm probably in a minority of one.
I'd recommend filtering ALL user input - not just GET vars. Every request can predict failry precisely in advance what parameters (keys and values) it should receive from GP&C and can check for values within allowed ranges as well as various checks for missing or alien keys.
Gee mom, are you SURE you checked those cookies?
So, you're saying that all filters are executed (pre and post) after the front controller has executed? What do you see as problems when loading a front controller into a filter chain?
Matt
p.s. Always wondering about your Dynamic Engine and the posibility of seeing some good examples!
It's just semantics really: in this case the FilterManager would actually be the FrontController.
The DynamicEngine was a very early OOP "brainwave" written when I was pretty green and didn't realise how big personal breakthroughs weren't really so wonderful as they seemed.Dynamic Engine and the posibility of seeing some good examples!
It solved a problem I had with building pages in sections: basically it creates a queue of objects (corresponding to individual page sections or blocks as they are sometimes called). Everything observes everything else so (for example) a Head class can gather a page title and keywords from other page bits. A pipe manager object is also registered as an observer: the actual data being output on the page gets transferred to that.
I wouldn't make any claims for it whatsoever but feel free to steal anything in the unlikely event that it might be useful. I'd expect it would have some similarities to a filter manager, which also is an object queue at heart.
I'm not the best person to ask about Intercepting Filters. I tend to think the pattern is badly defined and conceived - perhaps I've still got some shades of green to deal with...
Anyway, here's a couple of links:
Wact Wiki FrontController
Wact Wiki InterceptingFilter
hi,
Ok, I looked at the links.
Basically, it does say that the last filter of the chain should be a special filter to be called in order to access the application logic. That would basically be like what the example showed in this thread earlier about intercepting filters.
So then the front controller could initialize them, say in a method called run; and then a method called execute could be called when called by the previous filter. Then it can get started choosing what to do next.
This all is very interesting. I have been looking at phppatterns.com, and find it is about the best resource for this information. The articles are very informative; and it is interesting to see how many different opinions there are out there.
WindowMaker, thanks very much for your response - my new friend!I am reasonably new to the OO approach but thanks to this forum I've learnt a lot and come a long way in a short amount of time. Still learning though, as we all are.
If I replace Front Controller with Page Controller above, will your statement still be true? (say for a moment that I'm not using a FC aside from the web server).
Good point. FrontController initiates the FilterManager\Chain. Can a PageController also do the same?
Take for example that only some pages require authentication. I see three solutions:
1. Map all these into the FrontController so it knows which Filters to add to the chain
2. Use seperate PageControllers that know which Filters are required for that page
3. Use a combination. A FrontController for the secured pages, and a FrontController for the public pages.
Would that summarise the approaches? This is where I'm at in trying to make a decision.
Thanks again for your help.
Cheers,
Af.
It is a fiddly problem to solve. Following the principle of "resolve anything which is repeated into a single source", you might have a hierarchy of:
- filters common to ALL requests
- some more filters common to all requests in a particular site area
- finally, some filters specifically added for a particular request
It's quite likely that it can't be defined as neatly as that.
As you say, there has to be some means of dynamically adding filters to a FilterManager, according to the request (I guess it's possible that a given app might have a constant filter list for all requests, but an architecture which imposes that wouldn't be widely useful). I'm not sure if I know the best solution but I think all three options you mentioned are valid.
In regards to my earlier statement, authentication of a user if they're logged in or not can be delegated to a Filter ?
For authenticating if a user can carry out an action is a higher layer task, thus I think it belongs within the Front Controller.
You could I suppose have it in a Page Controller, but my feeling is that is too far down the application layer for this ?
Looking at Mojavi for a moment, for public/private pages, this frameworks Actions return a variable to determine which is which, public or private if I remember ?
I'm thinking that if I have a base Page Controller, and each sub Controller has a variable to determine a page is public or private, the Front Controller can determine prior to dispatching a Page Controller, via the base Page Controller what action to take ?
Then Front Controller has something to determine ?PHP Code:class PageController {
function authenticate() { }
}
...
class AddNewsPageController extends PageController {
var $policy = 'private';
function Dispatch() { }
...
}
...
This is off the top of my head just now, but it could be something like this ? I think the Front Controller should have the final say in what happens, as if user doesn't have the permission to edit news for example, and a page is private (ie requires permission) then you need to redirect yes ?PHP Code:...
if( !$page -> Authenticate( $_GET['Act'] ) ) {
... redirect to unauthorised action page ...
}
...
Shouldn't the Front Controller manage this then ? Maybe need more to clear this up I think
if I were making it I'd probably stick it in the page controller, or in the highest level possible that required authentication. I'm not quite sure what you call what the front controller selects...
btw I changed my code in my project now so that the fc initializes the filter chain but then the data ends up back at the front controller. So hopefully that's a bit better. now trying to figure out model methods...
Remember, the "FrontController" is not a science with a set of rules to be followed, it is a pattern and you describe that pattern with things it "can" do - but doesn't have to, and based on your implementation can vary quite differently.Good point. FrontController initiates the FilterManager\Chain. Can a PageController also do the same?
Take for example that only some pages require authentication. I see three solutions:
1. Map all these into the FrontController so it knows which Filters to add to the chain
2. Use seperate PageControllers that know which Filters are required for that page
3. Use a combination. A FrontController for the secured pages, and a FrontController for the public pages.
Would that summarise the approaches? This is where I'm at in trying to make a decision.
Take for example, Mojavi. Mojavi is a combination between a FrontController and an Application Controller. It does not dispatch to a separate application control, but implements a command-dictionary type design controlled by the file system layout as well as an intercepting filter. For many web applications - ranging from the very small to the very large, this is the architecture you have. You have a homogeneous system and you just want to give it structure. I say homogeneous because you aren't dispatching to other controllers really -- that level of complexity and deepness to the controller is rarely needed.
Now, another possible implementation of a frontcontroller is just a very "thin" controller that dispatches to different applications (whom in turn have their own application controller). This is a lot closer to a Java application where your applications are very thick, and they just implement an interface to the front controller for receiving information from the web server. I have found that PHP4 applications rarely need this, and in fact -- this is very counterintuitive to PHP's "shared nothing" architecture.
Remember, a PHP application is completely different than your Java servlet environment where you have a web container and applications running in that container. In PHP, everything is already sitting in the web server and any part in the script you have just as much access and ease of use with web server variables than any other script. Furthermore, a PHP script lasts for but an instant: created on a request, and then destroyed when the request is done so it makes sense to keep the application as lean as possible. Applications who don't keep it lean tend to feel slow and bloated (just try to run any of those PHP ports of Struts and you'll know what I mean). You don't need anything special to get something from the web server, or send something back to be served to the web browser. There is some added bonus from using something in the front, as opposed to just using a superglobal ($_GET, $_POST, etc) but if ya didn't and repeated addslashes() and htmlentities() a few extra times, it wouldn't kill you.
To wrap things up, a design pattern is just that -- a pattern, a way many people have come to attack a problem with solutions that are all similar. The solutions vary, and yes a frontcontroller "can" do this, and it makes sense to do one thing with the other, but not without it and the debate can never really end. Sometimes, I think a project is good with just Mojavi, sometimes I think a project needs a front controller to dispatch to other applications. Do you put authentication in a front controller? Perhaps, or maybe you dispatch to several applications that do their own authentication and some with no authentication at all.
P.S. Mojavi's psuedo command for loading modules has its own pluggable authentication/authorization API that you are free to use or not. In fact, that's my favorite part about Mojavi -- things aren't "built in" to the framework, it just provides a nice OO API to plugin your own stuff into Mojavi (a greaty way to keep a PHP project organized in my opinion).
I just read the Microsoft description of the Intercepting Filter pattern
and it says it ain't necessarily so:
"An interesting alternative implementation to the Intercepting Filter pattern uses the Decorator pattern around a Front Controller."
This probably proves your point that the pattern is "badly defined", since no-one seems to agree on what does what to what. Anyway, the real question is whether the essential functionality of the Front Controller should be in one place or the other. Or perhaps either way would work.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Another comment to the same statement. After reading Captain Proton's example in post #24 again, I can see that it actually does both: the front Controller loads itself into the chain of decorators. So it's both the initial access point (the run() method) and is also being run as a filter (the processRequest() method).
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
The FrontController, as I understand it, is a single point of access to the app. In the link you gave, "RequestHandler" is the single point of access and so I'd see that as a FrontController. The "concrete controller" I would say is a PageController.
I wouldn't personally like to treat the FC as both a centralised request handler and as a filter since I think this confuses its role. A class should be responsible for just one thing, as a rule.After reading Captain Proton's example in post #24 again, ... the front Controller ... is both the initial access point ... and is also being run as a filter...
I'm beginning to wonder if the discussion here about InterceptingFilter is following a similar "pattern" to the frequent questions about MVC on these forums, ie it is not providing an immediately clear and intuitive solution. Instead, it seems to be creating more questions than answers. That could be a fault of the pattern itself, how well it is explained, or maybe just part of the learning process.
In part I think the arbitrary (IMO) separation of pre, core and post processing which leads to InterceptingFilter is responsible for this, but I accept that this is one way of looking at things which suits many people.
At heart, there is a very simple process: load a bunch of objects each of which carries out an action (including serving the client page).
The classes should be as independent as is possible, and there will (usually) need to be some means of dynamically configuring the actions/tasks/commands list - whatever you want to call it.
Last edited by McGruff; Aug 13, 2004 at 20:57.
According to Fowler, the Front Controller has both a Web Handler which is the single point of access and a set of Commands.
Good point, but it looks to me like the FC's two jobs may be considered one responsibility. The FC is not acting as a filter; it controls main processing after the prefilters and before the postfilters.
I think both. The Great Gurus are groping just as we are. Fowler gets his concepts mixed up and the J2EE patterns people tend to focus on paraphernalia and avoid clarifying the main issue.
I think if Fowler had included the Intercepting Filter pattern in his book, we would have a better example to start with.
But I find Captain Proton's example excellent. It helped me understand the pattern better.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
The example was excellent, even though I understood the pattern easily enough, I hadn't seen an example as clear nor clean as that oneBut I find Captain Proton's example excellent. It helped me understand the pattern better.
On the Front Controller, Fowler suggests the use of the Front Controller with the Command pattern, but this is not a Front Controller requirement in it's self.
Shame also, that Fowler didn't explain the Command pattern either, since he made a reference to it. Btw, wasn't the Command pattern given a spot on the ISA site prior to the books publication ?
Think it was.
Perhaps not, but he states explicitly that the commands are part of the Controller.
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
I have too played with MVC for a while, and I came up with this kind of idea.
And here's a very simple example.PHP Code:<?php
abstract class JMVC_ActionController{
public $actions=array(); //Array of registered actions
protected $model; //Reference to model
protected $view; //Reference to View
protected $requestPath;
public function __construct($requestPath){
$this->requestPath = $requestPath;
$this->initialize(); //Initialize before executing actions
foreach($this->actions as $action){
if (isset($_REQUEST[$action->getName()])) { //Execute requested actions
$action->execute();
$action->isExecuted() && $this->afterAction($action);
}
}
$this->main();
}
/**
* JMVC_ActionController::initialize()
*
* Initialize variables and register actions here.
*
* @return
**/
abstract protected function initialize();
/**
* JMVC_ActionController::afterAction()
*
* Method is called each time when any of the registered actions is executed.
*
* @return
**/
protected function afterAction(Action $action){}
/**
* JMVC_ActionController::main()
*
* Method is called after all requested actions are executed.
*
* @return
**/
abstract protected function main();
/**
* JMVC_ActionController::registerAction()
*
*
* @return
**/
protected function registerAction($name,$methods){
$methods = is_array($methods) ? $methods : array($methods);
$this->actions[$name]= new Action($name,$this,$methods);
}
}
class Action{
public $value = '';
public $name = '';
private $sender;
private $methods = array();
private $executed = false;
public $error = '';
public function __construct($name,JMVC_ActionController $sender,$methods){
if (!method_exists($sender, 'action_'.$name)) {
Throw new Exception('Action method ('.$name.') not implemented at Class: '.get_class($sender));
}
$this->name = $name;
$this->methods = $methods;
$this->sender = $sender;
}
public function getName(){
return $this->name;
}
public function getValue(){
return $this->value;
}
public function isExecuted(){
return $this->executed;
}
public function execute(){
$value = false;
if (in_array('POST', $this->methods) && isset($_POST[$this->name])) {
$value = empty_val($_POST[$this->name.'_value']);
}elseif (in_array('GET', $this->methods) && empty($value) && isset($_GET[$this->name])) {
$value = empty_val($_GET[$this->name]);
}else{
return;
}
try{
$this->value = $this->sender->{'action_'.$this->name}($value);
}catch (Exception $e){
if ($e instanceof ActionException) {
$this->error = $e->getMessage();
}
}
$this->executed = true;
}
}
?>
Idea is that you have to make own methods to every action in the controller class. Now you can call the script like this: index.php?add (action_add method is called)PHP Code:class Controller_example extends JMVC_ActionController{
function initialize(){
$this->registerAction('add','GET');
$this->registerAction('subtract','GET');
}
function main(){
$this->view = new View_example($this->model);
$this->view->display($this->requestPath);
}
function action_add($value=NULL){
$this->model->value++;
}
function action_subtract($value=NULL){
$this->model->value--;
}
}
}
index.php?subtract or (action_subtract is called)
index.php?add&subtract (both methods are called)
Basicly you can use extended ActionController class as front controller or page controller. So I'd just like to know what more expereinced OOP-gurus think about this. And please don't mind if my english is not very fluent, i type it so rarely. But I can read it very well
Posting Permissions
Bookmarks