Geekly Articles each Day
📜 ⬆️ ⬇️

Symfony 2.0 Overview, Part 2

So, continue to inspect the symfony 2.0 framework. In the first part, I described the contents of the symfony-sandbox application created 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/Symfony applications directory, we will see three directories:

In the first part, I wrote that the framework itself is a set of “bundles”; you can easily make sure of this by looking in the Framework directory, which contains:


WebBundle is probably the biggest bundle available at the moment. Here and 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.

Foundation content is similar 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 kernel “bundle”, EventDispatcher, the universal class autoloader, the abstract Bundle class that implements the BundleInterface interface, from which all the “bundles” are not followed.
')
Well, the contents of the Components - these are the components , but written in the style of PHP 5.3. Currently available:
This is not yet what is needed, it is the Forms sub-framework.

So, briefly, it works like this: when accessing the front web/index.php controller, an instance of the application's kernel class is created in our case, HelloKernel , which extends the Symfony\Foundation\Kernel class. When creating an object, two parameters are passed to the class constructor: the name of the environment and the debug flag enable true or false. The class constructor invokes the methods for registering bundles, registering search paths for bundles, registering the application root directory, and determining the name of the application itself. After that, in the front controller, the run() method is called in which the main work takes place. And again, briefly, the main work looks like this: the boot() method is executed in which the DI container is initialized (Dependency Injection Container), the methods for constructing the container of all connected “bundles” are called during initialization. After that, the method of loading the application settings is called. Then this entire constructed and formed container is written to the cache as a class, in order not to build it with each request, a file from the cache is connected and an instance of this generated container class is created.

After this, the boot() method of all connected "bundles" is called. Then the request object is pulled out of the container, by default it is an object of the class Symfony\Components\RequestHandler\Request . And then the request handler object is pulled out of the container, by default it is an object of the Symfony\Components\RequestHandler\RequestHandler , from which the handle() method is called and as a parameter it receives the already received request object. The handle() method must return a Symfony\Components\RequestHandler\Response response object, which in turn calls the send() method, which is responsible for sending the response (headers and bodies). Now, if it is short and rough, then the work of the kernel is limited to this. Everything else lies on the shoulders of "bundles."

Each bundle should have a class implementing the Symfony\Foundation\BundleInterface in which only two methods are buildContainer(ContainerInterface $container) registering parameters and services in the container and boot(ContainerInterface $container) which is responsible for loading the bundle, loading is already done after all the parameters and services of all the “bundles” are defined in the DI container. Most “bundles”, namely all “bundles” from Symfony/Framework extend the Symfony\Foundation\Bundle class and overlap only the builderContainer method to define their settings and services in the container.

For an example of how to use the boot() method of the class Bundle . By default, Webbundle's “bundle” uses a template engine based on Symfony\Components\Templating . But the templating.engine service in the WebBundle is defined in such a way that it does not allow you to transfer your Renderer classes to the constructor, while Symfony\Components\Templating\Engine in the constructor takes the second Renderer array as a second parameter. But thanks to the use of Dependency Injection Container, this slight misunderstanding is easily fixed. To do this, in our application, in the src/Application/HelloBundle/Bundle.php file in the Bundle class, we define the method:
 public function boot (ContainerInterface $ container)
 {
   $ container-> getTemplatingService () -> setRenderer ('name', new Renderer ());
 }

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

In all this review, I almost did not touch the work from the console. Outwardly, everything remains almost the same, except that the console controller is now created at the application level, and not at the level of the entire project, as it was in Symfony 1.x. But inside there were serious changes, there were additional opportunities, in more detail you can get acquainted while studying Components/Console . Another interesting feature has appeared - the symfony shell. It is enough to run hello/console -s and an interactive console session starts, to put it more simply, a symfony shell allows you to execute the same commands.

Symfony 2.0.0 Shell

That's basically finished a brief overview of symfony 2.0. The framework is of course still raw, in some situations unexpected errors occur, some things are not there yet. But the developers of the framework call to try and express their wishes, opinions and of course bug reports as well. So Wellcome!
Well, I'll try to make brief reviews about symfony / Components.

Source: https://habr.com/ru/post/89157/

More articles:


All Articles