Merge branch '2.0' into 2.1

Author: weaverryan

components/config/definition.rst

@@ -91,6 +91,20 @@ The root node itself is an array node, and has children, like the boolean
 node ``auto_connect`` and the scalar node ``default_connection``. In general:
 after defining a node, a call to ``end()`` takes you one step up in the hierarchy.
 
+Node type
+~~~~~~~~~
+
+It is possible to validate the type of a provided value by using the appropriate
+node definition. Node type are available for:
+
+* scalar
+* boolean
+* array
+* variable (no validation)
+
+and are created with ``node($name, $type)`` or their associated shortcut
+``xxxxNode($name)`` method.
+
 Array nodes
 ~~~~~~~~~~~
 

components/dependency_injection/compilation.rst

@@ -22,6 +22,8 @@ validity, further compiler passes are used to optimize the configuration
 before it is cached. For example, private services and abstract services
 are removed, and aliases are resolved.
 
+.. _components-dependency-injection-extension:
+
 Managing Configuration with Extensions
 --------------------------------------
 
@@ -238,6 +240,8 @@ but also load a secondary one only if a certain parameter is set::
     You should instead use a compiler pass which works with the full container
     after the extensions have been processed.
 
+.. _components-dependency-injection-compiler-passes:
+
 Creating a Compiler Pass
 ------------------------
 
@@ -307,6 +311,8 @@ For example, to run your custom pass after the default removal passes have been
     $container = new ContainerBuilder();
     $container->addCompilerPass(new CustomCompilerPass, PassConfig::TYPE_AFTER_REMOVING);
 
+.. _components-dependency-injection-dumping:
+
 Dumping the Configuration for Performance
 -----------------------------------------
 

components/dependency_injection/introduction.rst

@@ -194,6 +194,8 @@ difficult to reuse the class elsewhere.
 You will need to get a service from the container at some point but this
 should be as few times as possible at the entry point to your application.
 
+.. _components-dependency-injection-loading-config:
+
 Setting Up the Container with Configuration Files
 -------------------------------------------------
 

components/dependency_injection/workflow.rst

@@ -0,0 +1,78 @@
+.. index::
+   single: Dependency Injection; Workflow
+
+Container Building Workflow
+===========================
+
+In the preceding pages of this section, there has been little to say about
+where the various files and classes should be located. This is because this
+depends on the application, library or framework in which you want to use
+the container. Looking at how the container is configured and built 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
+of the service container configuration from the application and bundles and
+also handles the compilation and caching. Even if you are not using ``HttpKernel``,
+it should give you an idea of one way of organizing configuration in a modular
+application.
+
+Working with cached Container
+-----------------------------
+
+Before building it, the kernel checks to see if a cached version of the container
+exists. The ``HttpKernel`` has a debug setting and if this is false, the
+cached version is used if it exists. If debug is true then the kernel
+:doc:`checks to see if configuration is fresh<components/config/caching>`
+and if it is, the cached version of the container is. If not then the container
+is built from the application-level configuration and the bundles's extension
+configuration.
+
+Read :ref:`Dumping the Configuration for Performance<components-dependency-injection-dumping>`
+for more details.
+
+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
+allows for different configuration for different environments e.g. dev, prod.
+
+These files contain parameters and services that are loaded directly into
+the container as per :ref:`Setting Up the Container with Configuration Files<components-dependency-injection-loading-config>`.
+They also contain configuration that is 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.
+
+Bundle-level Configuration with Extensions
+------------------------------------------
+
+By convention, each bundle contains an Extension class which is in the bundle's
+``DependencyInjection`` directory. These are registered with the ``ContainerBuilder``
+when the kernel is booted. When the ``ContainerBuilder`` is :doc:`compiled<components/dependency-injection/compilation>`,
+the application-level configuration 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 application-level config is usually processed
+with a :doc:`Configuration object<components/config/definition>` also stored
+in the bundle's ``DependencyInjection`` directory.
+
+Compiler passes to allow Interaction between Bundles
+----------------------------------------------------
+
+:ref:`Compiler passes<components-dependency-injection-compiler-passes>` are
+used to allow interaction between different bundles as they cannot affect
+each others configuration in the extension classes. One of the main uses is
+to process tagged services, allowing bundles to register services to picked
+up by other bundles, such as Monolog loggers, Twig extensions and Data Collectors
+for the Web Profiler. Compiler passes are usually placed in the bundle's
+``DependencyInjection/Compiler`` directory.
+
+Compilation and Caching
+-----------------------
+
+After the compilation process has loaded the services from the configuration,
+extensions and the compiler passes, it is dumped so that the cache can be used
+next time. The dumped version is then used during subsequent request as it
+is more efficient.

cookbook/doctrine/reverse_engineering.rst

@@ -92,6 +92,13 @@ The generated ``BlogPost.dcm.xml`` metadata file looks as follows:
       </entity>
     </doctrine-mapping>
 
+.. note::
+
+    If you have ``oneToMany`` relationships between your entities,
+    you will need to edit the generated ``xml`` or ``yml`` files to add
+    a section on the specific entities for ``oneToMany`` defining the
+    ``inversedBy`` and the ``mappedBy`` pieces.
+
 Once the metadata files are generated, you can ask Doctrine to import the
 schema and build related entity classes by executing the following two commands.