Adventures in Zend Framework 2: Episode 2: The Basics

You've Been Framed!

Zend Framework 2 (ZF2) describes itself as "the most popular framework for modern, high-perfoming PHP applications" [1]. It is an open source project which is primarily used for developing web applications and services which uses "100% object-oriented code and utilises most of the new features of PHP 5.3, namely namespaces, late static binding, lambda functions and closures." [2] It is essentially a library of components which can be used separately or together, designed to work most effectively within an MVC implementation.

My first experiences of ZF2 came through utilising VuFind 2 [3] and much of what I am going to write about ZF2 is done so through the prism of VuFind. With that said, I have begun to use ZF2 in other projects and some of the experience I have of certain components such as Forms and Access Control Lists has come through my own experimentation.

Funny Bones

The first port of call for anyone interested in ZF2 (after reading as much literature as possible) should probably be the Skeleton Application available at http://framework.zend.com/downloads/skeleton-app. It offers a step-by-step guide to getting a ZF2 application started using the most common components like databases and forms and gives a basic introduction to the MVC concept. As part of the installation process, the user will also be encouraged to use Composer [4], a dependency manager for PHP which makes adding and using third party software extremely easy. I also recommend familarising yourself with Git [5] and Github [6] as the preferred version control system.

MVC

The Model-View-Controller software pattern to which ZF2 adheres is basically a means of arranging code into logical but integrated sections, separating a developer's representation of information "from the ways that information is presented to or accepted from the user". [7] The model encapsulates the core code complete with the logic and functions required to generate or manipulate data, the view constitutes any outputted representation of this information whilst the controller effectively acts as a  go-between the model and the view, accepting and converting user input into commands for each.

Explaining how the MVC process works in ZF2 could take up the entire contents of a book, let alone a blog post. At the beginning, I suffered some sleepless nights as my brain tried to make sense of some terribly complex diagrams which I managed to find online. Anything I offer here will necessarily be a gross simplification but it may at least offer a base for further exploration.

1) Bootstrap

All the requirements for running the application (including dependencies) are prepared

2) Route

A user request is matched to a controller and action

3) Dispatch

The controller processes the application logic chain

4) Render

The information is represented to the user

5) Finish

The MVC process is complete

Each of these "phases" have different "hooks" which allow a developer to attach or inject logic when required. Some "hooks" are already predefined (such as just before and just after rendering takes place) but a developer can also add their own. In ZF2, these "hooks" are actually "events" (as it made clear by naming conventions which use "pre", "post", "on" etc as descriptions) and an "Event Listener" is responsible for dealing with the separate MVC phases. I will cover the Event Manager and listening to events in a later post.

This MVC structure is partly revealed in the directory structure of the Skeleton Application:

A simplified flow of  information through a ZF2 application would therefore run something like this:

1. A user makes a request via a url
2. Web server redirects force all requests via the index.php file in the public folder (unless the requested filename actually exists e.g. images, css files etc)
3. index.php begins the auto loading process by requiring init_autoloader.php and initialising any dependencies in the vendor directory (including ZF2 which is a dependency of the Skeleton Application)
4. index.php begins the MVC process, using the configuration settings found in config/application.config.php. Settings include an array of module namespaces (e.g. "Application"), the locations in which modules should be found (e.g. "modules" and "vendor"), overriding configuration files and options for caching.
5. Modules are loaded and initialised via the Module Manager, largely through the operation of Module.php (which contains "onBootstrap" and "init" methods plus methods for establishing the module configuration and library location e.g. module/Application/src/Application) and config/module.config.php. Module configuration files are merged with the application configuration to create the final configuration.
6. The Service Locator (responsible for locating predefined services) plus the Router, View and Event services are set up so that they can be used in the Bootstrap phase.
7. After bootstrapping, the MVC logic is processed as the route is determined from the url, a controller and action are selected, the model code is executed, the response is determined (and rendered if required) and the request is finished.

Coming Up...

In my next post, I'll highlight some of ZF2's major features. It was only once I'd got my head around them that the ZF2 penny began to drop.

[1] http://framework.zend.com/
[2] http://framework.zend.com/about/
[3] http://www.vufind.org
[4] https://getcomposer.org/
[5] http://git-scm.com/
[6] https://github.com/
[7] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller