Symfony 2.0 at a glance

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, do not take these statements to heart, which is really important - it has become faster and more flexible.

Symfony 2 is currently under development and is not ready for use in production. But to try in order to study, it is already possible. I want to start acquaintance with a review of the application based on the framework. Symfony 2 sources on github . There's also a ready sandbox app on githubbuilt on Symfony 2.0, but in it the version of Symfony is slightly different from the last. Therefore, after receiving the source sandbox, the first thing I did was replace the version of Symfony with src/vendor/symfonythe latest.

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 the directory structure of the application is completely different. Namely, there are three directories: hello, src, web.

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

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


The front controller connects the application core class, instantiates the class, defines the environment, and launches the application by calling the method run.

The application directory hello/contains an application core class that extends the abstract classSymfony\Foundation\Kerneland makes basic definitions. In particular, the application’s root directory is determined, the “bundles” are recorded (which is what Symfony and applications built on it now consist of), the paths along which to search for the “bundles” are registered, the Dependency Injection Container is created and the routing rules are registered. Methods creating an IOC container and defining routing rules in the implementation by default load configuration files from the application directory hello/. Here, in the kernel class, two important files are connected src/autoload.phpand src/vendor/symfony/src/Symfony/Foundation/bootstrap.phpnecessary for the kernel to work correctly, in particular, autoload.phpan instance of the class is created Symfony\Foundation\UnversalClassLoaderand paths for auto-loading files with classes are configured. Paths are defined by two methods.registerNamespaces- allowing you to specify paths for searching for classes by their namespace (namespace); and registerPrefixes- allowing you to specify paths for searching files by class prefixes, for example Swift_, Zend_i.e. for classes written in the style of PHP version lower than 5.3

In the same directory is a file hello/console- an analogue of the file symfonyin Symfony 1.x, i.e. a tool that allows you to execute various commands from the console.
Here are the directories:

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

The source directory src/contains the above-mentioned file src/autoload.phpand directories:

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

HelloBundle contains:

• the Bundle bundle class is an extension of 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

An important point - the framework does not determine the structure of directories and does not impose any restrictions. If you look at the kernel class of our application, we will see that all the paths are written there. And we can change them at our discretion. This directory structure was proposed specifically by the sandbox application and will probably be offered as default in the future.

Having examined the directory structure of the application, you can try to find out where the promised flexibility is hiding and what exactly can be changed. Well, to be honest, the directory structure itself is the first thing that we can change at our discretion. Symfony 1.x had a directoryapps/containing various applications using common code. In our case, this directory is not, but different applications can be created and it can be done in a way convenient 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 application hello. We can add another application, for example bye. Or we can simply add the class of the new application ByeKernelto the directory by hello/writing the root directory of the application in it. By the way, no one forbids creating a directory apps/in which to place applications. In general, in terms of directory structure, everything is very flexible.

The next interesting place is the bundles. The “bundle” is the “first-class citizens” in Symfony, it is a structured set of files that implement certain functionality and which can easily be used by other developers in other applications. These are not exactly the same as plugins in Symfony 1.x, as I said above. The closest analogy 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 that you are developing is also a “bundle,” or a set of “bundles.” This allows you to flexibly configure applications and connect functionality packaged in “bundles”, it also makes it possible to distribute code by packaging it in a “bundle”.

For example, in the sandbox application, which I took from github, if you look at the kernel class, you can see which "bundles" are used and this 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 the application does is print Hello and the name passed in the parameters, you can safely disable DoctrineBundle, SwiftmailerBundle.

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

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

Interestingly, the files config_dev.ymland config_prod.ymlinclude the file config.ymlusing the instruction importsis 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, it seems, kernel.configdetermines the settings for the "bundle". Some “bundles” can have several occurrences, such as WebBundleone that has two occurrences web.web. web.templating
For each environment, you can override the settings of “bundles”, for example, as 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, we can highlight the following interesting points. The framework is based on the idea of ​​a micro-kernel with plug-in "bundles." This all binds using the Dependency Injection Container. As a result, you can add / remove functionality in the application by connecting / disconnecting "bundles", which can also be customized using Yaml or XML configuration 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 .