Symfony 2.0 overview

Symfony 2 has undergone major changes compared to the 1.x branch. The framework has become more flexible and faster. Now, according to the developers, this is one of the fastest frameworks written in PHP, you can see the numbers here . However, one should not take these statements to heart, which is really important - it has become faster and more flexible.

Currently, Symfony 2 is still in development and is not ready for use in production. But to try in order to study, it is already possible. Introduction I want to start with a review of the application based on the framework. Symfony 2 sources on github . In the same place on github there is a ready-made sandbox application built on Symfony 2.0, but in it the Symfony version is somewhat different from the last one. Therefore, after receiving the sandbox source, first of all I replaced the symfony version in src/vendor/symfony with the latest one.

 git clone git: //github.com/symfony/symfony-sandbox.git sandbox
 cd sandbox / src / vendor
 rm -rf symfony
 git clone git: //github.com/symfony/symfony symfony

So, the first thing that catches your eye is that the application directory structure is completely different. Namely, there are three directories: hello, src, web.

• hello/ : directory named after the application and containing configuration files.
• src/ : all PHP code is stored here.
• web/ : web server root directory.

The root directory of the web server contains all the files available from the web, such as images, style sheets, javascript. Also here are the front index.php controllers - for the production environment and index_dev.php - for the development environment. In general, everything is as before, with one exception, here a useful check.php script check.php that allows you to check the environment for compliance with the system requirements of Symfony 2.0.

')
The front controller connects the application's class to the kernel, creates an instance of the class, defines the environment, and starts the application by calling the run method.

The hello/ application directory contains an application kernel class that extends the abstract Symfony\Foundation\Kernel class and makes basic definitions. In particular, the root directory of the application is defined here, “bundles” are registered (which is what Symfony consists of and applications built on it now), paths to search for “bundles” are registered, Dependency Injection Container is created and routing rules are registered. Methods that create an IOC container and define routing rules in the default implementation load configuration files from the hello/ application directory. Here in the kernel class two important src/autoload.php and src/vendor/symfony/src/Symfony/Foundation/bootstrap.php needed for the kernel to work properly, in particular, an instance of the Symfony\Foundation\UnversalClassLoader class is created in Symfony\Foundation\UnversalClassLoader and set up paths for auto-uploading files with classes. Paths are defined by two methods registerNamespaces - allowing you to specify paths for searching classes by their namespaces and registerPrefixes - allowing you to specify file paths by class prefixes, for example Swift_ , Zend_ ie for classes written in the PHP version of the version below 5.3

In the same directory is the hello/console file - an analogue of the symfony file in symfony 1.x, i.e. tool allows you to perform various commands from the console.
Here are the directories:

• hello/cache : for cache
• hello/logs : for logs
• hello/config : for configuration files

The src/autoload.php file already mentioned above and the directories are in the source directory src/ :

• src/Application : contains the “bundles” of our web application, in this case HelloBundle
• src/Bundle : contains third-party or shared “bundles” between several applications, in our case there is nothing
• src/vendor : contains source code for third-party libraries, in our case it contains doctrine , swiftmailer , symfony , zend

The HelloBundle contains:

• The Bundle Bundle class extends the Symfony \ Foundation \ Bundle \ Bundle class, which in turn implements the Symfony \ Foundation \ Bundle \ BundleInterface interface
• HelloBundle/Controller/HelloController.php : application controller
• HelloBundle/Resources : bundle resources including templates

The important point is that the framework does not define the directory structure and does not impose any restrictions. If you look into the kernel class of our application, you will see that all paths are registered there. And we can change them at our discretion. This directory structure is proposed by the sandbox application and will probably be offered as default in the future.

After reviewing the directory structure of the application, you can try to find out where the promised flexibility is hidden and what exactly can be changed. Well, to be honest, the directory structure itself is the first thing we can change at our discretion. In symfony 1.x, there was an apps/ directory containing various applications using common code. In our case, this directory is not, but different applications can be created and can be done in a convenient way for us. For example, you can create application directories on the same level as src/ and web/ , i.e. as done in our case with the hello application. We can add another application, for example bye . Or we can simply add the class of the new application ByeKernel to the hello/ directory hello/ setting the root directory of the application in it. By the way, no one forbids creating an apps/ directory in which to host applications. In general, in terms of directory structure, everything is very flexible.

The next interesting place is the bundles. A “bundle” is “first-class citizens” in symfony, it is a structured set of files that implement certain functionality and that can be easily used by other developers in other applications. This is not exactly the same as the plugins in symfony 1.x, as I said above. The closest analogy that I found for myself is the “application” in Django. In Symfony 2, everything consists of “bundles”, the framework itself is a set of “bundles”, the application you are developing is also a “bundle” or a set of “bundles”. This allows you to flexibly configure applications and connect the functionality packaged in bundles, it also gives you the opportunity to distribute the code by packaging it in bundle.

For example, in the sandbox application that I took from github, if you look into the kernel class, you can see which “bundles” are used and it will be:

• Symfony\Foundation\Bundle\KernelBundle
• Symfony\Framework\WebBundle\Bundle
• Symfony\Framework\ZendBundle\Bundle
• Symfony\Framework\SwiftmailerBundle\Bundle
• Symfony\Framework\DoctrineBundle\Bundle
• Application\HelloBundle\Bundle

Based on the fact that all that the application does is that it prints Hello and the name passed in the parameters, you can safely disable DoctrineBundle, SwiftmailerBundle.

Each bundle can be customized using configuration files. The application configs are located in the hello/config/ directory. In particular, there are:

• hello/config/config.yml : general settings
• hello/config/config_dev.yml : settings for the dev environment
• hello/config/config_prod.yml : settings for prod environment
• hello/config/routing.yml : routing rules

Interestingly, the config_dev.yml and config_prod.yml files config_dev.yml config_prod.yml file config.yml imports instruction, imports is very convenient. If you open the file config.yml , then it has settings for the connected "bundles".

 # hello / config / config.yml
 kernel.config: ~
 web.web: ~
 web.templating: ~

Each entry, like kernel.config defines the settings for the “bundle”. Some bundles can have several entries, such as the WebBundle , which has two entries, web.web and web.templating
For each environment, you can override the settings of "bundles", for example, as is done in config_dev.yml :

 # hello / config / config_dev.yml
 imports:
   - {resource: config.yml}
 web.debug:
   exception:% kernel.debug%
   toolbar:% kernel.debug%

 zend.logger:
   priority: info
   path:% kernel.root_dir% / logs /% kernel.environment% .log

So, summing up the review of the application, you can highlight the following interesting points. The framework is based on the idea of ​​micro-kernels with pluggable “bundles”. It binds all using Dependency Injection Container. As a result, you can add / remove functionality in the application by connecting / disconnecting “bundles”, which can also be customized using the Yaml configuration or XML files. You can disable or replace parts of the framework itself by disabling or replacing the “bundles”.
Now you can briefly familiarize yourself with the contents of the framework itself, which I will do in the next part .