Symfony 2.0 Overview, Part 2

    So, I continue to inspect the Symfony 2.0 framework. In the first part, I described the contents of a symfony-sandbox application built on the basis of Symfony 2.0. In this part I will look into the contents of the framework itself.

    Going to the src/vendor/symfony/src/Symfonyapplication directory , we will see three directories:
    • Components
    • Foundation
    • Framework

    In the first part I wrote that the framework itself is a set of “bundles” that can be easily verified by looking at the directory Frameworkin which you find:
    • Framework/DoctrineBundle: this is Doctrine ORM
    • Framework/ProfilerBundle: this is a friend of the developer - toolbar
    • Framework/SwiftmailerBundle: Swift mailer
    • Framework/WebBundle: web, templating, user
    • Framework/ZendBundle: Zend library, now using Zend_Log

    WebBundle is perhaps the largest “bundle” currently available. Here is the Controller from which the application controller is inherited, and the User class and sessions, and templating and util and skeleton for the application and for the bundle. In general, it is interesting to look into it, but not this time.

    The content is Foundationsimilar to the core code library, i.e. it contains code that allows this miracle to work as it should. In particular, the base class of the kernel, the “bundle” of the kernel, EventDispatcher, the universal class autoloader, the abstract Bundle class that implements the BundleInterface interface from which all bundles are not traced.

    Well, the contents Componentsare the very components , but written in the style of PHP 5.3. Currently available:
    • Components / Console
    • DependencyInjectionContainer
    • Eventdispatcher
    • OutputEscaper
    • RequestHandler
    • Routing
    • Templating
    • Yaml
    That's what is not yet needed, so it is a sub-framework of Forms.

    So, in short, it works something like this: when accessing the front controller web/index.php, an instance of the application core class is created in our case HelloKernel, which extends the class Symfony\Foundation\Kernel. When creating an object, two parameters are passed to the constructor of the class: the name of the environment and the debug enable flag true or false. In the class constructor, the methods of registering “bundles”, registering ways to search for “bundles”, registering the root directory of the application are called, and the name of the application itself is determined. After that, the method run()in which the main work is performed is called to the front controller . And again, in short, the main work looks like this: the method is executedboot()in which the DI container (Dependency Injection Container) is initialized, methods of building the container of all connected "bundles" are called during initialization. After that, the method for loading application settings is called. Then all this built and formed container is written to the cache as a class, so as not to build it with every request, a file from the cache is connected and an instance of this formed container class is created.

    After that, the method of boot()all connected "bundles" is called. Then the request object is pulled out of the container, by default it is a class object Symfony\Components\RequestHandler\Request. And then the request handler object is pulled out of the container, by default it is a class object Symfony\Components\RequestHandler\RequestHandler, the method of which is called handle()and the already received request object is passed to it as a parameter. Methodhandle()should return a response object Symfony\Components\RequestHandler\Response, which in turn calls the method send()that is responsible for sending the response (headers and body). Now, if briefly and roughly, this limits the work of the kernel. Everything else rests on the shoulders of the "bundles."

    Each “bundle” must have a class that implements an interface Symfony\Foundation\BundleInterfacein which only two methods buildContainer(ContainerInterface $container)are defined that register parameters and services in the container and boot(ContainerInterface $container)which is responsible for loading the “bundle”, loading is done after all parameters and services of all “bundles” are defined in the DI container. Most of the “bundles”, namely all “bundles” from Symfony/Frameworkextend the class Symfony\Foundation\Bundleand override only the method builderContainerfor defining their settings and services in the container.

    As an example, how can I use the boot()class method Bundle. By default, the WebBundle "bundle" uses a template engine based on Symfony\Components\Templating. But the service templating.enginein the WebBundle is defined in such a way that it does not allow you to pass your Renderer classes to the constructor, while Symfony\Components\Templating\Enginein the constructor it takes an array of custom Renderers as the second parameter. But thanks to the Dependency Injection Container, this slight misunderstanding is easily fixed. To do this, in our application in the file src/Application/HelloBundle/Bundle.phpin the class Bundlewe define the method:
    public function boot (ContainerInterface $ container)
      $ container-> getTemplatingService () -> setRenderer ('name', new Renderer ());

    where the class Rendereris our custom renderer, and the 'name'name of this renderer. Now when displaying templates, you can use your own renderer.

    Throughout this review, I practically did not touch on the work from the console. Outwardly, everything remained almost the same, with the exception that the console controller is now created at the application level, and not at the project level, as it was in Symfony 1.x. But inside there have been serious changes, additional features have appeared, which you can learn more about by studying Components/Console. Another interesting feature has appeared - Symfony shell. It is enough to start hello/console -sand start an interactive console session, in other words, the Symfony shell allows you to execute the same commands.

    Symfony 2.0.0 shell

    So in general, a brief overview of Symfony 2.0 has ended. The framework is of course still raw, in some situations unexpected errors occur, some things still do not. But the developers of the framework urge you to try and express your wishes, opinions and, of course, bug reports as well. So Wellcome!
    Well, I'll try to make brief reviews about Symfony / Components.

    Also popular now: