Page Controller Pt.2

However, as the web application grow, the controller part may become very complex. As we know, a web page is a collection of sections which combined together to become a page – header, sidebar, main content, footer, banner etc. are sections (or whatever you call it). Therefore, it would be very complex when we need to include all this in a single controller. We can separate the smaller sections to another class or put it in our toolbox functions class, but it might be temporary before you may need it to act like a main controller. Here’s where the difference comes:

  • Most framework (that I know) only consist of single MVC, which designed to handle one simple request (CRUD operation of a blog post is a simple request)
  • A way to overcome this is by abstracting similar logics to a parent class, and let controller extends it. However not all conditions require those extra logics to be loaded for all requests.

Then I read http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/, an extension to ordinary MVC. It’s a collection of MVC triad that are independent to each other, and one MVC become the main controller. By using this idea, we can redesign our front controller to support HMVC and make it ready for a complex application

  1. Front controller received request, parse, delegate to target page controller as usual, and run the target controller.
  2. From within main controller, we may call another controller for different sections in that particular page.
  3. All sub controllers that being called from main controller will be independent of each other – make it look like requesting a different page. We may call it asynchronously (from within PHP, using cURL and get the response in whatever format)
  4. These subcontrollers doesn’t need to be reside in the same server or same script directory with the main controllers, it can be put in different server and act as a background service, interact using RPC, SOAP or other web service protocol

What’s more interesting is all these can be achieved without having to allocate too much resource as in term of development time (all can be done in PHP), server (one server can achieved all these) and maintainability (all components are structured and modularized – given you’re writing proper documentation and comments on the code). Take a look at Kohana or CodeIgniter if you’re interested to include this feature into your web application.

Page Controller

Having read http://www.phpwact.org/pattern/centralized_request_logic, one thought comes to mind, which one the better preferred way to code the page controller for PHP.

The page controller is the common pattern, where a file handles one web page and all of its actions. Files are being accessed directly. Base class usually being used to refactor the code. E.g http://domainname.tld/about.php, http://domainname.tld/search.php – these php files are independent from each other. Older PHP scripts are using this method, and it’s quite hard to maintain the code.

Intercepting filters being implemented by prepend the page controller script with an input filter script and append it with an output filter.  These controllers will include a header file (input filter) at the beginning of the script and include a footer file (output filter) to the end of the script. Having need to include the filter files on every page we created is quite cumbersome, and also the filter files need to handle many types of request, and sometimes the page controllers doesn’t need all of those extra functions to handle specific requests. phpBB is one of the PHP scripts that using this pattern.

Front controller pattern is having one central point to accept request and dispatch it to appropriate page controllers. This is common for all modern framework such as CakePHP, YiiFramework and DooPHP. Also these frameworks utilize the dynamic invocation method, where it doesn’t store the registry of modules and plugins it has – the framework will lookup the script directory to find appropriate controllers to handle the request. It is a drawback for static invocation method since it stores a large list of modules or plugins which need to be loaded on every requests, and it surely not needed all the time by all of the controllers.

Therefore, I conclude that the best way to code the page controller is by implementing dynamic invocation of front controller, similar to other frameworks. Here’s the program flow:

  1. Front controller received a request.
  2. Parse the request to determine which page controller to load, which action to run and what parameter need to be set
  3. Load target controller or show error page not found
  4. Target controller will need to extend some base class that share same logic with other controllers.
  5. Run the target action, determine  how to display the output