发布于 2015-08-27 16:41:51 | 107 次阅读 | 评论: 0 | 来源: 网络整理
The section 如何掌握和创建新的运行环境 explained the basics on how Symfony uses environments to run your application with different configuration settings. This section will explain a bit more in-depth what happens when your application is bootstrapped. To hook into this process, you need to understand three parts that work together:
注解
Usually, you will not need to define your own front controller or
AppKernel class as the Symfony Standard Edition provides
sensible default implementations.
This documentation section is provided to explain what is going on behind the scenes.
The front controller is a well-known design pattern; it is a section of code that all requests served by an application run through.
In the Symfony Standard Edition, this role is taken by the app.php
and app_dev.php files in the web/ directory. These are the very
first PHP scripts executed when a request is processed.
The main purpose of the front controller is to create an instance of the
AppKernel (more on that in a second), make it handle the request
and return the resulting response to the browser.
Because every request is routed through it, the front controller can be used to perform global initializations prior to setting up the kernel or to decorate the kernel with additional features. Examples include:
The front controller can be chosen by requesting URLs like:
http://localhost/app_dev.php/some/path/...
As you can see, this URL contains the PHP script to be used as the front
controller. You can use that to easily switch the front controller or use
a custom one by placing it in the web/ directory (e.g. app_cache.php).
When using Apache and the RewriteRule shipped with the Standard Edition,
you can omit the filename from the URL and the RewriteRule will use app.php
as the default one.
注解
Pretty much every other web server should be able to achieve a behavior similar to that of the RewriteRule described above. Check your server documentation for details or see Web服务器的配置.
注解
Make sure you appropriately secure your front controllers against unauthorized access. For example, you don’t want to make a debugging environment available to arbitrary users in your production environment.
Technically, the app/console script used when running Symfony on the command line is also a front controller, only that is not used for web, but for command line requests.
The Kernel is the core of
Symfony. It is responsible for setting up all the bundles that make up
your application and providing them with the application’s configuration.
It then creates the service container before serving requests in its
handle()
method.
There are two methods declared in the
KernelInterface that are
left unimplemented in Kernel
and thus serve as template methods:
registerBundles(),
which must return an array of all bundles needed to run the
application;registerContainerConfiguration(),
which loads the application configuration.To fill these (small) blanks, your application needs to subclass the
Kernel and implement these methods. The resulting class is conventionally
called the AppKernel.
Again, the Symfony Standard Edition provides an AppKernel in the app/
directory. This class uses the name of the environment - which is passed to
the Kernel’s constructor
method and is available via getEnvironment() -
to decide which bundles to create. The logic for that is in registerBundles(),
a method meant to be extended by you when you start adding bundles to your
application.
You are, of course, free to create your own, alternative or additional
AppKernel variants. All you need is to adapt your (or add a new) front
controller to make use of the new kernel.
注解
The name and location of the AppKernel is not fixed. When
putting multiple Kernels into a single application,
it might therefore make sense to add additional sub-directories,
for example app/admin/AdminKernel.php and
app/api/ApiKernel.php. All that matters is that your front
controller is able to create an instance of the appropriate
kernel.
Having different AppKernels might be useful to enable different front
controllers (on potentially different servers) to run parts of your application
independently (for example, the admin UI, the frontend UI and database migrations).
注解
There’s a lot more the AppKernel can be used for, for example
overriding the default directory structure.
But odds are high that you don’t need to change things like this on the
fly by having several AppKernel implementations.
As just mentioned, the AppKernel has to implement another method -
registerContainerConfiguration().
This method is responsible for loading the application’s
configuration from the right environment.
Environments have been covered extensively
in the previous chapter,
and you probably remember that the Standard Edition comes with three
of them - dev, prod and test.
More technically, these names are nothing more than strings passed from the
front controller to the AppKernel‘s constructor. This name can then be
used in the registerContainerConfiguration()
method to decide which configuration files to load.
The Standard Edition’s AppKernel class implements this method by simply
loading the app/config/config_*environment*.yml file. You are, of course,
free to implement this method differently if you need a more sophisticated
way of loading your configuration.