I currently design all of my websites with a file for each page, then include common elements like the header, footer and so on. However, I've noticed that many frameworks and CMSs use the Front Controller pattern.
What are the advantages and disadvantages of using a Front Controller? Is the pattern simply used in frameworks and CMSs because it's not known which pages will exist in the final system?
Srikanth has a good answer. I'd like to elaborate on the alternative, though. Suppose you have this simple URL hierarchy:
/gallery /blog /admin/login /admin/newpost
If this is implemented with Page Controllers (PHP, for example), both gallery.php and blog.php will need to include some common.php at the beginning (or nearby). However, both login.php and newpost.php may include admin-common.php, which itself pulls in 'common.php' and does '/admin/'-specific setup, like verifying the user is authenticated.
In general, if you have a hierarchy of URLs, it ends up looking a lot like object inheritance trees. Except instead of using language-level inheritance, you're inheriting the environment of whatever foo-common.php you include.
I can't imagine how a Front Controller is increasing testability, In the end, the exact same tests from an automated HTTP user-agent are required, regardless of implementation.
One major downside of Page Controllers is it does make your web application dependent upon its hosting environment. It also forces your developers to "see" the same structure as end users, but I consider that a good thing, considering the number of sites I see that have absolutely atrocious URLs.