+1  A: 

Without having a detailed look on your code:

Try to write code that is self-explanatory by using meaningful function and variable names. Only use comments where the purpose or the functioning of your code is not clear. E.g.

//Declaring variable(s)
//Class construct method
//Checks for existance of file
//Includes file

are useless comments because the code itself is already clear enough.

A book worth reading: Clean Code

Felix Kling
I concur with this answer. You'll run into many people with wild beliefs in comments ranging from "Your code should be 50% comments, and 50% code" (a professor when I was in school) to "Programmers don't need comments, that's just there for people who can't read code" (someone on DreamInCode). Comments should explain things that are confusing, and save time. You don't need to explain how to program, you don't need to be overly verbose, but you need to explain generally what your code is trying to do, and anything that's really complicated is worth explaining.
I have requested that book from my library. I will also try to remove the comments you pointed out. Any other feedback? Thanks again for your help!
Drew2345
A: 

Your code is very remeiscent of CakePhp. I'd recommend checking that out, it does all of this work with App::import() and a File class that wraps the filesystem. It's tested by a community on different versions and OSes, it will in fact save you time.

Lincoln B
A: 

I am torn between closevoting as too localized and wanting to comment on the code. Also, it's too much code to wade through now, so I will comment only a few things:

1) Documentation style

Why not use an established documentation format, like PHPDoc?

2) Formatting

is consistent as far as I can see, but I suggest to use a coding convention that is in wide use, like that of PEAR or ZF (which is based on PEAR) instead of doing your own (yours is close to PEAR anyway, so you might as well adopt it completely).

3) Singleton pattern

In order for the Singleton to work it has to have a private __contruct and __clone method. But I suggest not to use it at all. Many people believe the Singleton is an AntiPattern. There are a number of questions on SO discussing the disadvantages of the Singleton pattern, so have a look around. If there should be only one instance, then simply dont instantiate a second one. If you need to access the FrontController in other classes, inject it.

4) Method length

I probably would try to shorten the dispatch method. Basically, if you describe what a method does and you have to use an and to do so, that part should go into it's own method. Try to make methods into small discrete units. That will make UnitTesting easier as well.

5) Separation of Concerns

I am not sure why the FrontController extends from ActionController. There is no other classes that extent it, butI suppose the classes the FrontController instantiates are subclasses of ActionController too. But the FrontController, while named a controller, does different things than the PageControllers, so I'd probably keep them separated.

On a sidenote, if you are interested in increasing the quality of your code, have a look at the slides and tools given at http://phpqatools.org/

Gordon
I thought I was conforming to the PEAR conventions. In what way am I not? Thanks for your feedback!
Drew2345
Which specific methods would you recommend shortening?
Drew2345
@Drew For instance, there should be indentation after the class opening. Curly braces in functions and class definitions should start at the new line. Private members, but not proteced, should be preceded by a single underscore. You can use PHP_CodeSniffer to see where it's off.
Gordon
@Gordon - I sent you an e-mail...
Drew2345