A quick tour of the skeleton application — Zend Framework 2 2.3.9 documentation
Getting Started With Zend Studio 10 & Zend Server 6
A quick tour of the skeleton application¶
The skeleton application provides a lot of files, so it’s worth having a quick high-level look at what has been generated for us. There are a number of high level directories created for us (along with Composer and other support files):
|config||Application-level configuration files.|
|data||Data files generated by the application, such as caches.|
|module||The source files that make up this application are stored within separate modules within this folder.|
|public||The web server’s document root. All files served directly by the web server are in here.|
|vendor||Third party libraries.|
One of the key features of Zend Framework 2 is its module system. This provides organisation within your application; all application code lives within a module. The skeleton provides the Application module for bootstrapping, error and routing configuration. It also provides the application-level controllers for the home page and error display. The Application module contains these key folders:
|config||Module-specific configuration files.|
|src/Application||PHP files for this module, including controller and model files. The controller for the home page, IndexController.php, is provided.|
|view/application||View scripts for each controller action.|
|view/error||Error view scripts for 404 and generic errors.|
|view/layout||Layout view scripts. These contain the common HTML shared by a number of pages within the website. An initial default file, layout.phtml, is provided.|
Modules are simply namespaces containing a top level Module class. They are intended to be reusable and no additional constraints are placed on how they are organised. An application consists of multiple modules, both third party and application specific, with the list of modules to load stored in config/application.config.php.
The dispatch cycle¶
To set up the application for running, a number of things happen. Firstly an instance of Zend\ServiceManager is created as the master locator for all class instances used by the application. The Module Manager is then used to load all the application’s modules. It does this by reading its configuration file, application.config.php, which is solely for use by the Module Manager and does not contain the configuration used by the application itself.
The modules are loaded in the order listed in the configuration file and for each module a number of steps takes place:
- Configuration of autoloading.
- Loading of module configuration.
- Registration of event listeners.
- Configuration of the Service Manager.
The configuration information from all modules is merged together into one configuration array. This means that configuration information in subsequent modules can override information already set. Finally, the global configuration files stored in the config/autoload directory are merged (the *.global.php and then the *.local.php files). This means that any module’s configuration can be overridden at the application level and is a key feature that helps to ensure that the code within a third-party module does not need to be changed.
The Service Manager and Event Manager are two other key features of a Zend Framework 2 application. Zend\ServiceManager allows for decoupling the instantiation and configuration of a class and its dependencies from where that class is used. This is known as Dependency Injection and is used extensively in Zend Framework 2. Zend\EventManager is an implementation of the Observer design pattern which allows decoupling of code. In Zend Framework 2, every key process in the dispatch cycle is implemented as an event. This means that you can write listeners for these events which can then change the flow of operation or perform additional processes when something else has happened.
Once all modules have been loaded, the application is run. This is done as a series of events, with the first event, route, used to determine the controller action that should be run based on the URL requested. Once this is determined, the dispatch event is triggered which causes the action method within the controller class to be executed. The view rendering event, render, is then triggered if an HTML view is required. Finally the finish event is triggered which sends the response back to the user’s web browser.
While this is a typical dispatch cycle, Zend Framework 2’s dispatch system is very flexible and can be configured in a variety of ways depending on the specific application. Now that we’ve looked at how Zend Framework works, let’s move on and write the MyTaskList application.