Blueprint PHP Framework Tutorial – Part 4 (Controllers)

The last tutorial in this series covered how the router decides which controller/method to invoke based on the request URL. In part 4, we are going to look at the structure of the controller. You can set up your controller in any way you like, but there are just a few rules you should follow. I will also show you how I build my controllers to make best use of the components in the framework.

Just before we get into all this, I just want to make a quick aside. You should be familiar with how the namespacing works by now, and we should set up our namespace structure in such a way that the autoloader can load the classes for us when they are called. A suggested structure might be:

  • app
    • {namespace}
      • Controller
      • Form
      • Model
      • View

With this structure in place we can start to build out first controller. For the purpose of this tutorial, we will call our namespace ‘Frontend’. Here is a very basic structure of the simplest controller.

As you can see, the first thing we need to do is set the namespace. As this is a controller under the Frontend directory, the namespace will be Frontend\Controller. Also, we are extending the Blueprint controller, so we need to tell the script where this is: Blueprint\Controller\Controller. Finally we will be making use of the a view to push the output through. So we need to tell the script where that is too: Blueprint\View\PageView.

There are then three parts to the controller.

  • The constructor
  • setContainer method
  • action methods

The constructor is used to set up the model (we aren’t using one in this simple example) and the view. Of course, this assumes that all of the actions in the controller are going to make use of the same model and view. If not, you would set these individually in each action.

The setContainer() method is the place where you can pull out the dependencies that any of the action methods will make use of. By setting the dependencies as properties of the controller, the action can just call $this->{dependency} when they want to use them. The other thing that the setContainer method does is set the containers of the model and the view, thereby passing the dependencies into them too. Of course it would be more efficient to just pass the dependencies they are actually going to use but this is just a quick way of passing everything that was setup in the bootstrap script to the model and view. Feel free to restrict things like this any way you want.

Finally, we arrive at the action methods. They follow a CamelCase naming convention with the first letter in lowercase and ending in ‘Action’. All these methods need to do is call various methods in the model and pass the output to the view which will render the response. The default render() method of the view (which extends the Blueprint\View\PageView which in turn extends Blueprint\View\View) takes two parameters. The first is the location of template to use to render the output. By stating that we want to use ‘index.php’, we will be using /out/index.php. The second parameter is an array of variables that the template requires. These could be breadcrumbs, result sets, tables, h1’s etc but will will just dump everything in one variable: $vars[‘content’];.

Then the /out/index.php just needs to:

and your done!

As you can see, controllers are dead simple. Next time I’ll go over a simple model and tie it into the controller. Also in a later tutorial, I’ll go over the view in a little more detail too.

One thought on “Blueprint PHP Framework Tutorial – Part 4 (Controllers)

Leave a Reply