To hopefully clear up some MVC confusion

[pallan]

Earlier in the thread Captain Proton posted this

How common are those things to all Page Controllers? For the public section of a website, you don't need to authenticate users, right? I personally prefer to implement sessions & authentication through the use of InterceptingFilters. The FrontController can set these up. But you can achieve the same thing by having multiple PageController base classes: one for pages that do need authentication, one for those that don't need authentication, one for those that need authentication and sessions, one for those that only need sessions... see why a chain of intercepting filters might be more flexible?

Thanks to the latest example that have been provided I really see what it meant. However, I do have another question, where does one setup which filters should be run? 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 example InterceptingFilter has already paid off dividends in the progress of my project, thank you very much.

Peer

[Brenden Vickery]

He may talk about a View Helper, but your User Helper is not a View Helper. A View Helper is a class that contains logic that is really business logic but it's business logic that is only required by a small number of Views, and implementing it into the business objects themselves would make them bloated, that is why they are in a separate class.

I dont know the term "View Helper" but I wouldnt put business logic in a class that specificly relates to the view. I dont see why a business object shouldnt have bussiness logic. Putting business logic in a view object is not a good answer IMO. View objects should only have presentation logic if any.

Whether or not you should use a Helper like below in php is a different discussion, I was only offering a solution for otnemem.

To exactly quote his example from PoEAA pg 355-357:

class Artist {
  private $name;
  private $albums = array();
  public function getName() {
    return $this->name;
  }
  public function getAlbums() {
    return $this->albums;
  }
}
class ArtistHelper {
  private $artist;
  public function ArtistHelper(Artist $artist) {
    $this->artist = $artist;
  }
  public function getName() {
    return $this->artist->getName();
  }
  public function getAlbums() {
    return $this->artist->getAlbums();
  }
  public function getAlblumList() {
    $result = '<ul>';
    foreach($this->getAlbumns() as $album) {
      $result = '<li>' . $album->getTitle() . '</li>';
    }
    return $result . '</ul>';
  }
}
$artist = Artist::findNamed($request->getParameter('name'));
if ($artist == null) {
    // foward to Missing artist error
} else {
    // Below is a jsp/servlet thing.
    // but is passing the artist to the
    // view via a helper
    $request->setAttribute('helper', new ArtistHelper($artist));
} 

[seratonin]

.. and .. I assume chain actions are a chain of Commands? If so, if you use Commands for things like session tracking you might ask yourself this question "Does a user want to do session management or is he/she really not interested in that?" Because, like you said, Commands are "what a user wants to do".

By chaining I meant more like a pipe and filter or intercepting filter (poor choice of wording) type architecture. Which would be something that happens internally when the Front Controller is carrying out a request. Although, you could definitely chain together two use cases. If you have a use case like Update News and you want to immediately forward control to View News upon success, I could see something like that happening. I am using use cases/features to help me partition my application. If View News is a use case what has to happen behind the scenes to provide that functionality is a completely different story. It may include authentication, authorization, logging, but that is all behind the scenes. What the user sees and cares about is viewing the news. So there is what the user observes is happening and what is happening internally.

JT

[Captain Proton]

I dont know the term "View Helper" but I wouldnt put business logic in a class that specificly relates to the view. I dont see why a business object shouldnt have bussiness logic. Putting business logic in a view object is not a good answer IMO

If you read what I said precisely, you'll see that I did not say that a business object should not have business logic. That wouldn't make sense of course. What I said is that some business logic might only be required by a very small number of views and if you have to add all of this business logic to the business objects themselves, they would become very bloated objects with dozens of methods.

To exactly quote his example from PoEAA pg 355-357:

I wasn't aware the book contained PHP code examples as well.. ? ..

[Brenden Vickery]

If you read what I said precisely, you'll see that I did not say that a business object should not have business logic. That wouldn't make sense of course. What I said is that some business logic might only be required by a very small number of views and if you have to add all of this business logic to the business objects themselves, they would become very bloated objects with dozens of methods.

Youre right. The point is that a Helper Object will restrict the use of domain logic in the view.

I wasn't aware the book contained PHP code examples as well.. ? ..

You caught me. I added dollars signs and a foreach instead of an iterator.

[McGruff]

is there any type of significant performance/overhead issues between FrontControllers and PageController implementations?

The only additional "burden" imposed by a FrontController is the webserver functionality. In a pure PageController setup, apache (or etc) carries out this task instead saving on a small chunk of code. However, if a FC selects PCs by dynamically including files, any losses are more theoretical than real. Lengthy switch cases or other methods such as xml files might be another matter.

Apart from that, FC and FC-less designs all have to do exactly the same thing (with the same amount of code) namely carry out a series of tasks in response to an http request.

There is, as far as I can see, no strong argument to use one design over the other - your choice. Harry Fuecks, on phppatterns.com, does make the point that FC-less designs may make it easier to integrate different apps.

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. Why pluck the client page out of the filter chain? And, if not this, why do the rest like that? I know a lot of people like to conceptualise things this way - just my opinion.

[cyberlot]

While I don't fully agree with making everything under the sun a object, there is a better way and more expandable way to do this instead of using a switch statement, the following gets rid of ever having to edit your core code to expand. It does add a certain limitation though on class names.

    if($_REQUEST['page']) {
          $method = 'User'.$_REQUEST['page'].'controller';
          if(class_exists($method)) {
       $pageController = New $method;
          }
    } 

Just wanted to add.. This assumes you already loaded all your librarys from the beginning, so theres no need to do live "taint" and includes based off the REQUEST making things more secure..

Taint checking is fine and all but you should only use it if you have no choice.. Imaging what would happen to half the php programs that rely so much on includes and taint checking if some bug is found in what ever function you use to taint check that allows something to slip by.

[pallan]

Alright, Captain Proton, I have another question for you about the Intercepting filters. In another thread (http://www.sitepoint.com/forums/showthread.php?t=157003) you said this

But the difficulty I am having is how do you have the various objects communicate with each other ?...But how to let the other lower down objects know about the higher up objects ?

You don't. InterceptingFilter is an application of the (more general) Chain of Responsibility pattern. Key to this pattern is that each object in the chain can either handle the request or pass it on to the next object in the chain (the target), without knowing what specific object that target is.

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?

(geez, this thread is making me thing far too hard for a Friday!)

Peer

[Widow Maker]

how do I tell my Front Controller that authorization failed and it needs to load the AuthorizationFailedController?

Not sure, though untested, I was thinking that you put a variable in $_REQUEST, and the next filter up would check for this ?

On the other hand, has anyone implemented an Observer with an Front Controller/Intercepting Filter, say to moniter the status of each filter ?

[Brenden Vickery]

   if($_REQUEST['page']) {
         $method = 'User'.$_REQUEST['page'].'controller';
         if(class_exists($method)) {
      $pageController = New $method;
         }
   } 

Just wanted to add.. This assumes you already loaded all your librarys from the beginning, so theres no need to do live "taint" and includes based off the REQUEST making things more secure..

You wouldnt want to include all of your libraries on each request. This will cause alot of unnessesary overhead.

A front controller at a minimum needs to have a default page to show if no $_REQUEST['page'] param is given. It also needs to be able to tell the difference between a valid $_REQUEST['page'] and non-valid one, creating the PageController on a valid and sending a 404 or creating the 404PageController on a non valid request.

Heres the example Ive used before:

class FrontController {
    var $defaultPageController;
    var $requestPageParam;
    var $pageControllers = array();

    function FrontController($defaultPageController, $requestPageParam = 'page') {
        $this->defaultPageController = $defaultPageController;
        $this->requestPageParam = $requestPageParam;
    } 

    function &getPageController() {
        $pageControllerName = $this->getPageControllerName();
        return $this->getPageControllerInstance($pageControllerName);
    } 

    function addPage($name, $className) {
        $this->pageControllers[$name] = $className;
    } 

    function getPageControllerName() {
        if (!array_key_exists($this->requestPageParam, $_GET)) {
            return $this->defaultPageController;
        } 
        return $_GET[$this->requestPageParam];
    } 

    function &getPageControllerInstance($pageControllerName) {
        if (!array_key_exists($pageControllerName, $this->pageControllers)) {
            header("HTTP/1.0 404 Not Found");
            die();
            // Do the above or the below.
            require_once './controller/Error404PageController.php';
            return new Error404PageController();
        } 
        require_once './controller/' . $this->pageControllers[$pageControllerName] . '.php';
        return new $this->pageControllers[$pageControllerName]();
    } 
} 
$fc = new FrontController('index');
$fc->addPage('index', 'IndexController');
$fc->addPage('admin', 'AdminController');
$pc =& $fc->getPageController();
// Below could be moved into the FrontController
$pc->execute();
// Below could be moved into the PageController
$view =& $pc->getView();
$view->render(); 

[cyberlot]

You wouldnt want to include all of your libraries on each request. This will cause alot of unnessesary overhead.

What I provided was just the very basic of examples.

It depends on how large your site is. You could also php5's overload system but then you have to do taint checking, The whole 404 and defaults are simple to add in.

[cyberlot]

  if($_REQUEST['page') {
      $method = 'User'.$_REQUEST['page'].'controller';
      if(!class_exists($methd)) {    
          $method = 'User404controller';
      }
  } else {
      $method = 'UserHomecontroller';
  }
  $pageController = New $method; 

Quick and simple.. Doesnt require editing the code to add a new controller.

If you want to limit loading to just a single library, You can use php5 autoload.. The great thing about that, by using autoload you are auto filtering the request php will not let you create a class with any char's someone might use to inject attack your system.

Controllers are nice and all but you have to look at what your ultimate goal is.
If your developering for yourself or a internal project thats fine but if your developing for the public you have to assume the person installing your code may not know php, The idea of editing a core file of the system could very well turn them away from ever using your product.

[Brenden Vickery]

 if($_REQUEST['page') {
     $method = 'User'.$_REQUEST['page'].'controller';
     if(!class_exists($methd)) {    
         $method = 'User404controller';
     }
 } else {
     $method = 'UserHomecontroller';
 }
 $pageController = New $method; 

Well done. I only made comment because of the use of $_REQUEST like this. For someone who didnt know better they may take this example and use it in a more dangerous way by getting rid of the string contatenation.

If youre using something like this you need to be careful of the way youre files / directories / classes are named.

[Captain Proton]

Excellent post Captain Proton. You are now the author of an important and featured thread

Thanks, I'm honored!

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.

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?

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.

I dont know the term "View Helper" but I wouldnt put business logic in a class that specificly relates to the view

The guys at sun would [url=http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html[/url]

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

My apologies to you and to Brenden Vickery. You are right, I have mixed up a J2EE pattern with Martin Fowler's book.

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.

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.

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?

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.

function processRequest(HTTPRequest $request, HTTPResponse $response)
{
    if ($this->containsAuthenticationCredentials($request))
    {
        $this->nextFilter->processRequest($request, $response);
    }
    else
    {
        $pageController = $this->getAuthenticationPageController($request, $response);
        $pageController->execute();
        $view = $pageController->getView();
        $view->render();
    }
} 

I think the code is kind of self explaning, but feel free to ask questions of course is anything is not clear.

[pallan]

function processRequest(HTTPRequest $request, HTTPResponse $response)
{
    if ($this->containsAuthenticationCredentials($request))
    {
        $this->nextFilter->processRequest($request, $response);
    }
    else
    {
        $pageController = $this->getAuthenticationPageController($request, $response);
        $pageController->execute();
        $view = $pageController->getView();
        $view->render();
    }
} 

I think the code is kind of self explaning, but feel free to ask questions of course is anything is not clear.

Thanks for the example (again ). I think I was looking at the filters a little to literally. Some of the explanations I had read seemed to indicate that the InterceptingFilter either wasn't 'allowed' or 'supposed' to take control of specifying the PageController. I figured it could, but it didn't seem like 'good design'.

Out of curiosity, I notice you have two arguments in your processRequest function. The request var is pretty self -explanatory, but what type of information is usually passed in the $response argument?

Thanks

Peer

[Remy]

function processRequest(HTTPRequest $request, HTTPResponse $response)
{
    if ($this->containsAuthenticationCredentials($request))
    {
        $this->nextFilter->processRequest($request, $response);
    }
    else
    {
        $pageController = $this->getAuthenticationPageController($request, $response);
        $pageController->execute();
        $view = $pageController->getView();
        $view->render();
    }
} 

I think the code is kind of self explaning, but feel free to ask questions of course is anything is not clear.

I have something like this (i'm suprised that my code looks so much like your example ), but I have some doubts with passing the HTTPRequest and the HTTPResponse.

What if HTTPRequest and\or HTTPResponse are not needed for a specific request (can't think of an example right now...): I have then created an HTTPRequest (and\or HTTPResponse) Object that is not going to be used.

I am thinking to change the HTTPRequest and HTTPResponse to Singletons and not passing them around. I am thinking of this, because there can't be two or more HTTPRequest\HTTPResponse in one request and each object can ask for them if needed (HTTPResponse::getInstance()). What do you think?

...but what type of information is usually passed in the $response argument?

Look at a Java-example or at the .NET-example. Mine has many similarities to the Java and .NET-versions (don't know if Captain Proton uses the same concept...)

-Rémy

[Widow Maker]

...
{ 
        $pageController = $this->getAuthenticationPageController($request, $response); 
        $pageController->execute(); 
        $view = $pageController->getView(); 
        $view->render(); 
    }... 

In this event, I am thinking about just redirecting to required page as is ? Is that not simpler ?

[seratonin]

Seratonin, alright, but then I don't even see the difference between your Commands and my PageControllers, except the name of course.

Captain Proton,

I applaud your effort here to make things clear and simple, but I still think that you are blurring the definition of the page controller pattern by mixing the page controller and the front controller patterns together. Someone coming here wanting to understand the page controller pattern might be confused by how you are using the pattern. I propose that you name your new pattern something different than page controller to distinguish it from a true page controller pattern (as Fowler and others intended).

Thanks,

JT

[Gybbyl]

I personally loved your MVC implementation. Very very simple and to the point. Put a lot of things into perspective, and DID clear up some minor confusions that I had about the "pattern."

One thing (with disregard to all of the posts besides the first one, since I'm at work and can't read them atm) I would suggest (or rather just struck me as odd) is that you define a part View class and have all of your page views, user views, etc, inherit from that. You implicity implement an interface (an interface that defines the "render()" method) in your view classes, but it always make it that much more consistent and readable when you explicity implement one.

Maybe you just didn't have time, maybe you overlooked it, maybe this is just a simple example that I am overlooking.

Great work.

[AlexBrina]

I applaud your effort here to make things clear and simple, but I still think that you are blurring the definition of the page controller pattern by mixing the page controller and the front controller patterns together

Instead of: "there are differences" what about itemize the differences:
I don't think I'm the right person to do that but, what I see is: (and maybe I'm completely blind )

Front Controller
1. Intercepts all requests made by the client to the web server
2. Most times it's made by an "index.php", every link or submit in your page must call the "index.php".
3. You can code in this file all things you need like Auth, Sessions, Logging, whatever... pluggable or not.
4. Decides which PageController must be called to process the request: this can be made by a switch statement or you can "translate" the request to a path in your directory structure.

Page Controller
1. A class that is called BY the Front Controller (after doing the common things) to handle the request.
2. The PC "knows" which Model and View are needed to process the request, which is its unique responsability.

BasePageController
1. Is the PageController parent class, that in fact, can do the same things the FC do.
2. If you have different behaviours in your app, you can have different BasePCs, but you can have different FCs as well. Atm, I can't say which is the most flexible. Maybe the BasePC 'cause you won't need to call that same index.php all the time.

The pluggable things can be called by: (depending on your code style)
1. Intercepting Filters
2. Decorators
3. probably there are more choices...or even a combination of them...

well, I guess that's enough to make Masters blow me up

[seratonin]

Instead of: "there are differences" what about itemize the differences:

The most important difference is that a Front Controller and a Page Controller are not supposed to directly interact (as per their original intent in Core J2EE Patterns and PoEAA). What Captain Proton is proposing is a new pattern which combines the two which is fine, I just want people to understand that it is a new and different variant. If you are looking to implement the Front Controller or Page Controller patterns separately, I would recommend looking somewhere other than this thread. As far as examples in PHP, the Mojavi framework implements the Front Controller pattern and from what I can tell, the WACT framework implements the Page Controller pattern.

JT

[McGruff]

It might be useful to make a broader summary as well as AlexBrina's more detailed one.

Essentially the whole process is pretty simple despite all the ramifications being explored here. Something has to identify an application command (webserver or FrontController), and something has to choose which actions to execute in response to the command (FrontController or PageController).

PS: I've always thought that a PageController might be better named an ApplicationCommandController or etc - some sort of name which doesn't lead you to think that it's sole concern is to serve up a page.

[AlexBrina]

The most important difference is that a Front Controller and a Page Controller are not supposed to directly interact (as per their original intent in Core J2EE Patterns and PoEAA).

After reading PoEAA again I have to agree, they're not supposed to interact directly. I don't feel comfortable pointing conclusions but, for me, the part of the FC that decides what PC to call is called ApplicationController (as PoEAA AC example leads to), i.e. the connector between FC and PC.
The responsibilities of the AppCont are: 1. Deciding which domain logic to run; 2. Deciding which view to display. But wai-wai-wait, aren't these PC's responsibilities? ....well, before I go nuts with all these things, and because of the lack of straight definitions, I will assume that:
FC: Receives all requests. Do basic things. Forward the requested action (command) to the AC.
AC: Based on the requested action decides which Page to display and passes control to it (the PC).
PC: The one who knows wich Model and View must process the requested action.

What Captain Proton is proposing is a new pattern which combines the two which is fine.

Agree. I think these rules are not supposed to be that strict, we can mix them to please our taste.

[AlexBrina]

It might be useful to make a broader summary as well as AlexBrina's more detailed one.

Would be very nice if the Masters made that summary of responsibilities. I'd put that list (hopefully a big one) every where around here.

[Overunner]

First of all, many thanks to Captain Proton who started this thread and everyone who has contributed to it

Now, regarding:

When using a Front Controller would you recommend only using the one page access point (eg .index.php)? Or would it make any sense to have a FrontController for each section of your site (eg. UserFrontController, NewsFrontController, etc)? I ask because I can see the switch statement getting rather large in a single access point for a big site and this would seem to break it up into logical units.

The 2 choices I have with a FC regarding access points is:
1) Have a single page access point
2) Have multiple access points
(duh)

If I made my index.php the only page access point, I would constantly have to parse the URL to find out where the user is heading E.g If the user hits the 'products' button, I would have to parse out the appropriate $_GET-variable and maybe dynamically load its PageController (which then would render a suitable View). Or have I misunderstood something here?

If I had multiple access points, then it would allow me to have different pages like index.php, products.php, links.php etc. where each page has its own FC (like ProductFrontController LinksFrontController etc.)

My questions are, which method do you prefer for a medium-large e-commerce site? Also, will it be diffucult to implement Intercepting Filters/Decorators and such if I go with the second option? Does the options above have any common pitfalls?

Thanks