Understanding Front Controller

[KevinM1]

After a bit of a break for the holidays (and the company I did part-time work for closing down), I'm now back in the swing of trying to grasp larger OOP concepts.  I have downloaded Code Igniter, but I want to get some of the theory down before looking at a bulk of code.  My questions stem from reading Zandstra's PHP 5: Objects, Patterns, and Practice book.

 

Am I correct in viewing his Woo_Request class as being analogous to the Command pattern's CommandContext/RequestHelper class?

 

He mentions the problem of caching setting/configuration data and suggests using PHP itself.  What does he mean by that?

 

Overall, am I correct in viewing the general process as being:

 

1. Single point of entry (say, index.php).

2. All links having a recognized $_GET value.  The links themselves merely point back to the index page (say, "index.php?cmd=feedback").

3. When that request is delivered via the page reloading (since every link points back to itself), that's when the controller fires, serving up the right page based on the request.

 

If I'm more or less on the right track, I'll move onto figuring out Code Igniter's method of generating nice pathnames that reflect site navigation rather than ugly $_GET-filled URLs (so, "index.php/feedback" instead of "index.php?cmd=feedback").

[trq]

Yeah, sounds like your pretty much on the right track.

 

You might find this simple example usefull. I found it the other day whilst searching for a simple filter-chains example.

[448191]

He mentions the problem of caching setting/configuration data and suggests using PHP itself.  What does he mean by that?

 

If I recall correctly, he's saying that using native PHP is faster, but using a storage method such an XML file is more flexible and caching a resulting object can be nearly as fast.

 

If not, that's what he should be saying.

[KevinM1]

He mentions the problem of caching setting/configuration data and suggests using PHP itself.  What does he mean by that?

 

If I recall correctly, he's saying that using native PHP is faster, but using a storage method such an XML file is more flexible and caching a resulting object can be nearly as fast.

 

If not, that's what he should be saying.

 

Okay, so in other words, keeping config data as a PHP file is faster, as you can include/require it directly where necessary, but using an XML file (for example) is more flexible for the end user?

 

Makes sense.

[emehrkay]

Yeah, sounds like your pretty much on the right track.

 

You might find this simple example usefull. I found it the other day whilst searching for a simple filter-chains example.

 

Cool stuff. I am currently using a switch statement in an index page, but this approach is pretty cool. I'll read more into it

 

edit*

How is this front controller different than a factory if at all?

[448191]

How is this front controller different than a factory if at all?

 

I don't really see the resemblance. That said, implementations of patterns are often alike. It the INTENT that should be associated with he handle.

 

I found it the other day whilst searching for a simple filter-chains example.

 

Take a look at Intercepting Filter. A simple implementation would just have an ordered list of filter objects in the Front Controller, which are allowed to manipulate the Request object before dispatching. There's not much else too it.

[emehrkay]

I compared it to a factory because a factory returns an instance of a class based on some params. This front controller does a little bit more by running methods/setting properties, but at its core, it looks like a factory to me.

[448191]

Calling it a Factory just because it does this:

 

$controller = new $class();

 

is a going a bit far IMO. It's not contained in a meaningful unit, and most importantly, it's not the main purpose of the unit.

 

Say it had a method like this:

 

public function controllerFactory($page){

      $class = ucfirst($page) . "Actions";

      return new $class();

}

 

Then you could say it's a Front Controller with a Factory Method.