The config folder consists of the following objects by default:

Probably the most important file in this folder would be the application.config.php as it contains all of our main configuration options. If we open this file we can see that it has a couple of options set to make our application work.

The file contains, for example, the modules key, which tells the framework which modules we need to load in for our application. It also contains the module_listener_options - module_paths, which tells our framework where to find our modules and libraries, which modules and vendor are by default.

The config folder also contains an autoload folder, which in itself contains two files which are the global configuration override and the local configuration override files. Both files are empty by default.

The default module folder consists of the following important objects:

The application module gives away the basic structure that we would like to see when creating a new module. The most important file that we see here is the Module.php, which tells the framework how our module is built up, where it can find our controllers, and many more.

Depending on how our application is built up, we would also want to have a configuration file for each module as we would like to keep the application as dynamic as possible. In the skeleton application we can see that our Module.php contains a method called Module::getConfig(); all it does is a simple include to the config/module.config.php file. Although we theoretically could just define the configuration in the Module.php,it is nicer if we separate the actual configuration file from our code, as that also brings a lot more maintainability with itself if we don't need to change the code for a simple change in configuration.

We can also see a language folder in this folder, which contains all the i18n (short for internationalization as it contains 18 characters between I and N) files needed for translating our application. Although probably used by a lot of developers, not all of our application will require translation, so we might not need this folder at all in our project.

But if we do require i18n and l10n (localization) then it would be beneficial to do this module wise instead of application wise, again for maintainability as we don't want the application (which is the whole application) to define i18n/l10n for all the modules, as theoretically not all of the modules have to be there. That is why working module oriented makes the code a lot more dynamic, but also maintainable as we can safely assume that if an error occurs in one of our modules, the problem also lies in that module.

The next folder src might very well be one of the most interesting folders in our module, as it contains—as we might have guessed—the source of our module. The folder src only contains another folder called Application, which is the defined namespace of the classes inside.

Make sure that you name your subdirectories in src to the namespace they are using. Otherwise it might not only lead to conflicts, but also confusion and inconsistencies. For example, if your module is called Winter, then our directory should be called src/Winter, to make sure that all our Winter namespaces are in that directory. That way we can safely assume that all our code for that namespace has been neatly put in that directory and its sub directories.

The subfolder in Application is in our skeleton application Controller, which contains only the IndexController.php. The IndexController.php is an extension of the Zend\Mvc\Controller\AbstractActionController, which is generally used for our day-to-day controllers; however, there is also the AbstractRestfulController in the same namespace, which we can use if we want to create a restful service.

Next up is the view folder, which contains all our view scripts. View scripts are basically template files we use to do the actual displaying to the user requesting the page. As we can see in the default module.config.php of our Application module, we have the view scripts configured to point to the view directory, which tells the framework that when it needs to find any view scripts, it should look in that folder.

As we can see the view folder is built up with the same structure as in the configuration file. The Application folder refers to the namespace which is using this view script that is, Application, then we see that there is also a layout defined, which is used as a global layout for our module—and the rest of the project if none is defined elsewhere—and an error folder, that is only used whenever an error occurs in the application. If we want to read up more about how the layouts work in Zend Framework 2, you should take a look at Chapter 4, Using View.

That concludes the buildup of our module folder, and when creating other modules—when using the skeleton application—it requires us to use the same folder structure.

What's next?

After the public/index.php has loaded up the locations of known classes and namespaces, it is ready to start up the Zend Framework 2 MVC application.

1. Get the config/application.config.php file. It actually doesn't do anything with this file at the moment.

2. Run the Zend\Mvc\Application::init($configurationArray), where $configurationArray is the variable that contains the read configuration from step 1.

   • Initialization of the ServiceManager, which handles all the services in the application.

     Invoke Zend\EventManager\SharedEventManager.

     Factory Zend\ModuleManager\ModuleManager.

   • Request the ModuleManager from the ServiceManager and run its loadModules() method.

   • This will then resolve all the modules and load in the module-specific configurations.

   • Request the Zend\Mvc\Application from the ServiceManager.

   • It will run the bootstrap() method.

3. The public/index.php will now execute the run() method on the fully initialized Zend\Mvc\Application, which will make the sure the routing, which will trigger the bootstrap, route, dispatch, render and finish events, making sure the application has done what was requested of it.

4. After the Zend\Mvc\Application has completed its run() method, it will execute the send() method, which will send the output made by the run() method back to the client.

Here is a flow chart diagram to show how the process goes a bit more graphically: