Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit d67d44a

Browse filesBrowse files
weaverryanweaverryan
committed
Merge pull request #1730 from richardmiller/adding_di_workflow
Adding an overview of how the service container concepts fit togther
2 parents ac47a4d + d56d2ea commit d67d44a
Copy full SHA for d67d44a

File tree

Expand file treeCollapse file tree

3 files changed

+82
-0
lines changed
Filter options
Expand file treeCollapse file tree

3 files changed

+82
-0
lines changed

‎components/dependency_injection/compilation.rst

Copy file name to clipboardExpand all lines: components/dependency_injection/compilation.rst
+6Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,8 @@ validity, further compiler passes are used to optimize the configuration
2222
before it is cached. For example, private services and abstract services
2323
are removed, and aliases are resolved.
2424

25+
.. _components-dependency-injection-extension:
26+
2527
Managing Configuration with Extensions
2628
--------------------------------------
2729

@@ -238,6 +240,8 @@ but also load a secondary one only if a certain parameter is set::
238240
You should instead use a compiler pass which works with the full container
239241
after the extensions have been processed.
240242

243+
.. _components-dependency-injection-compiler-passes:
244+
241245
Creating a Compiler Pass
242246
------------------------
243247

@@ -307,6 +311,8 @@ For example, to run your custom pass after the default removal passes have been
307311
$container = new ContainerBuilder();
308312
$container->addCompilerPass(new CustomCompilerPass, PassConfig::TYPE_AFTER_REMOVING);
309313

314+
.. _components-dependency-injection-dumping:
315+
310316
Dumping the Configuration for Performance
311317
-----------------------------------------
312318

‎components/dependency_injection/introduction.rst

Copy file name to clipboardExpand all lines: components/dependency_injection/introduction.rst
+2Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -194,6 +194,8 @@ difficult to reuse the class elsewhere.
194194
You will need to get a service from the container at some point but this
195195
should be as few times as possible at the entry point to your application.
196196

197+
.. _components-dependency-injection-loading-config:
198+
197199
Setting Up the Container with Configuration Files
198200
-------------------------------------------------
199201

‎components/dependency_injection/workflow.rst

Copy file name to clipboard
+74Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
.. index::
2+
single: Dependency Injection; Workflow
3+
4+
Container Building Workflow
5+
===========================
6+
7+
In the preceding pages of this section of the components there has been
8+
little to say where the various files and classes should be located. This
9+
is because this depends on the application, library or framework you want
10+
to use the container in. Looking at how the container is configured and built
11+
in the Symfony2 full stack framework will help you see how this all fits
12+
together whether you are using the full stack framework or looking to use
13+
the service container in another application.
14+
15+
The full stack framework uses the ``HttpKernel`` component to manage the loading
16+
of service container configuration from the app level and from bundles as well
17+
as with the compilation and caching. Even if you are not using the ``HttpKernel``
18+
it should give you an idea of a way of organising configuration in a modular
19+
application.
20+
21+
Working with cached container
22+
-----------------------------
23+
24+
Before building the container a cached version is checked for. The ``HttpKernel``
25+
has a debug setting, if this is false then the cached version is used if it
26+
exists. If debug is true then the :doc:`cached configuration is checked for freshness<components/config/caching>`
27+
and the cached version of the container used if it is. If not then the container
28+
is built from the app level configuration and the bundle's extension configuration.
29+
Read :ref:`Dumping the Configuration for Performance<components-dependency-injection-dumping>`
30+
for more details.
31+
32+
Application level configuration
33+
-------------------------------
34+
35+
Application level config is loaded from the ``app/config`` directory. Multiple
36+
files are loaded which are then merged when the extensions are processed. This
37+
allows for different config for different environments e.g. dev, prod.
38+
39+
These files contain parameters and services to be loaded directly into
40+
the container as per :ref:`Setting Up the Container with Configuration Files<components-dependency-injection-loading-config>`.
41+
They all contain config to be processed by extensions as per :ref:`Managing Configuration with Extensions<components-dependency-injection-extension>`.
42+
These are considered to be bundle configuration since each bundle contains
43+
an Extension class.
44+
45+
Bundle level config with extensions
46+
-----------------------------------
47+
48+
By convention each bundle contains an Extension class which is in the bundle's
49+
Dependency Injection directory. These are registered with the ``ContainerBuilder``
50+
when the Kernel is booted. When the ContainerBuilder is :doc:`compiled<components/dependency-injection/compilation>`
51+
the app level config relevant to the bundle's extension is passed to the Extension
52+
which also usually loads its own config file(s), typically from the bundle's
53+
``Resources/config`` directory. The app level config is usually processed with
54+
a :doc:`Configuration object<components/config/definition>` also stored in the
55+
bundle's ``DependencyInjection`` directory.
56+
57+
Compiler passes to allow interaction between bundles
58+
----------------------------------------------------
59+
60+
:ref:`Compiler passes<components-dependency-injection-compiler-passes>` are
61+
used to allow interaction between different bundles as they cannot affect
62+
each others configuration in the extension classes. One of the main uses is
63+
to process tagged services, allowing bundles to register services to picked
64+
up by other bundle, such as Monolog loggers, Twig extensions and Data Collectors
65+
for the Web Profiler. Compiler passes are usually placed in the bundle's
66+
``DependencyInjection/Compiler`` directory.
67+
68+
Compilation and caching
69+
-----------------------
70+
71+
After the compilation process has loaded the services from the configuration,
72+
extensions and the compiler passes it is dumped so that the cache can be used
73+
next time and the dumped version then used during the request as it is more
74+
efficient.

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.