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

Adding an overview of how the service container concepts fit togther #1730

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 3, 2012
Merged

Adding an overview of how the service container concepts fit togther #1730

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6f38035
Adding an overview of how the service container concepts fit togther
richardmiller-zz Sep 19, 2012
d56d2ea
Fixing some errors in di workflow page
richardmiller-zz Sep 20, 2012
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Fixing some errors in di workflow page
  • Loading branch information
@richardmiller-zz
richardmiller-zz committed Sep 20, 2012
commit d56d2ea03212eb582e68a5c64d547c734722c8e5
24 changes: 12 additions & 12 deletions 24 components/dependency_injection/workflow.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,18 +12,18 @@ in the Symfony2 full stack framework will help you see how this all fits
together whether you are using the full stack framework or looking to use
the service container in another application.

The full stack framework uses the ``HTTPKernel`` component to manage the loading
The full stack framework uses the ``HttpKernel`` component to manage the loading
of service container configuration from the app level and from bundles as well
as with the compilation and caching. Even if you are not using the ``HTTPKernel``
as with the compilation and caching. Even if you are not using the ``HttpKernel``
it should give you an idea of a way of organising configuration in a modular
application.

Working with cached controller
------------------------------
Working with cached container
-----------------------------

Before building the container a cached version is checked for. The ``HTTPKernel``
Before building the container a cached version is checked for. The ``HttpKernel``
has a debug setting, if this is false then the cached version is used if it
exists. If debug is true then the cached configuration is checked for freshness
exists. If debug is true then the :doc:`cached configuration is checked for freshness<components/config/caching>`
and the cached version of the container used if it is. If not then the container
is built from the app level configuration and the bundle's extension configuration.
Read :ref:`Dumping the Configuration for Performance<components-dependency-injection-dumping>`
Expand All @@ -33,12 +33,12 @@ Application level configuration
-------------------------------

Application level config is loaded from the ``app/config`` directory. Multiple
files are loaded which are then merged when the Extensions are processed. This
files are loaded which are then merged when the extensions are processed. This
allows for different config for different environments e.g. dev, prod.

These files contain parameters and services to be be loaded directly into
These files contain parameters and services to be loaded directly into
the container as per :ref:`Setting Up the Container with Configuration Files<components-dependency-injection-loading-config>`.
They all contain config to be processed by Extensions as per :ref:`Managing Configuration with Extensions<components-dependency-injection-extension>`.
They all contain config to be processed by extensions as per :ref:`Managing Configuration with Extensions<components-dependency-injection-extension>`.
These are considered to be bundle configuration since each bundle contains
an Extension class.

Expand All @@ -47,12 +47,12 @@ Bundle level config with extensions

By convention each bundle contains an Extension class which is in the bundle's
Dependency Injection directory. These are registered with the ``ContainerBuilder``
when the Kernel is booted. When the ContainerBundle is :doc:`compiled<components/dependency-injection/compilation>`
when the Kernel is booted. When the ContainerBuilder is :doc:`compiled<components/dependency-injection/compilation>`
the app level config relevant to the bundle's extension is passed to the Extension
which also usually loads its own config file(s), typically from the bundle's
``Resources/config`` directory. The app level config is usually processed with
a Configuration object also stored in the bundle's ``DependencyInjection``
directory.
a :doc:`Configuration object<components/config/definition>` also stored in the
bundle's ``DependencyInjection`` directory.

Compiler passes to allow interaction between bundles
----------------------------------------------------
Expand Down
Morty Proxy This is a proxified and sanitized view of the page, visit original site.