Merge branch '2.3'

Author: weaverryan

book/internals.rst

@@ -629,104 +629,8 @@ As the profiler adds some overhead, you might want to enable it only under
 certain circumstances in the production environment. The ``only-exceptions``
 settings limits profiling to 500 pages, but what if you want to get
 information when the client IP comes from a specific address, or for a limited
-portion of the website? You can use a request matcher:
-
-.. configuration-block::
-
-    .. code-block:: yaml
-
-        # enables the profiler only for request coming
-        # for the 192.168.0.0 network
-        framework:
-            profiler:
-                matcher: { ip: 192.168.0.0/24 }
-
-        # enables the profiler only for the /admin URLs
-        framework:
-            profiler:
-                matcher: { path: "^/admin/" }
-
-        # combine rules
-        framework:
-            profiler:
-                matcher: { ip: 192.168.0.0/24, path: "^/admin/" }
-
-        # use a custom matcher instance defined in
-        # the "custom_matcher" service
-        framework:
-            profiler:
-                matcher: { service: custom_matcher }
-
-    .. code-block:: xml
-
-        <!--
-            enables the profiler only for request coming
-            for the 192.168.0.0 network
-        -->
-        <framework:config>
-            <framework:profiler>
-                <framework:matcher ip="192.168.0.0/24" />
-            </framework:profiler>
-        </framework:config>
-
-        <!-- enables the profiler only for the /admin URLs -->
-        <framework:config>
-            <framework:profiler>
-                <framework:matcher path="^/admin/" />
-            </framework:profiler>
-        </framework:config>
-
-        <!-- combine rules -->
-        <framework:config>
-            <framework:profiler>
-                <framework:matcher ip="192.168.0.0/24" path="^/admin/" />
-            </framework:profiler>
-        </framework:config>
-
-        <!--
-            use a custom matcher instance defined in
-            the "custom_matcher" service
-        -->
-        <framework:config>
-            <framework:profiler>
-                <framework:matcher service="custom_matcher" />
-            </framework:profiler>
-        </framework:config>
-
-    .. code-block:: php
-
-        // enables the profiler only for request coming
-        // for the 192.168.0.0 network
-        $container->loadFromExtension('framework', array(
-            'profiler' => array(
-                'matcher' => array('ip' => '192.168.0.0/24'),
-            ),
-        ));
-
-        // enables the profiler only for the /admin URLs
-        $container->loadFromExtension('framework', array(
-            'profiler' => array(
-                'matcher' => array('path' => '^/admin/'),
-            ),
-        ));
-
-        // combine rules
-        $container->loadFromExtension('framework', array(
-            'profiler' => array(
-                'matcher' => array(
-                    'ip' => '192.168.0.0/24',
-                    'path' => '^/admin/',
-                ),
-            ),
-        ));
-
-        // use a custom matcher instance defined in
-        // the "custom_matcher" service
-        $container->loadFromExtension('framework', array(
-            'profiler' => array(
-                'matcher' => array('service' => 'custom_matcher'),
-            ),
-        ));
+portion of the website? You can use a Profiler Matcher, learn more about that
+in ":doc:`/cookbook/profiler/matchers`".
 
 Learn more from the Cookbook
 ----------------------------

book/routing.rst

@@ -1201,7 +1201,7 @@ By default, the router will generate relative URLs (e.g. ``/blog``). To generate
 an absolute URL, simply pass ``true`` to the third argument of the ``generate()``
 method::
 
-    $router->generate('blog_show', array('slug' => 'my-blog-post'), true);
+    $this->get('router')->generate('blog_show', array('slug' => 'my-blog-post'), true);
     // http://www.example.com/blog/my-blog-post
 
 .. note::
@@ -1212,7 +1212,7 @@ method::
     scripts run from the command line, you'll need to manually set the desired
     host on the ``RequestContext`` object::
 
-        $router->getContext()->setHost('www.example.com');
+        $this->get('router')->getContext()->setHost('www.example.com');
 
 .. index::
    single: Routing; Generating URLs in a template
@@ -1223,7 +1223,7 @@ Generating URLs with Query Strings
 The ``generate`` method takes an array of wildcard values to generate the URI.
 But if you pass extra ones, they will be added to the URI as a query string::
 
-    $router->generate('blog', array('page' => 2, 'category' => 'Symfony'));
+    $this->get('router')->generate('blog', array('page' => 2, 'category' => 'Symfony'));
     // /blog/2?category=Symfony
 
 Generating URLs from a template

components/event_dispatcher/immutable_dispatcher.rst

@@ -0,0 +1,41 @@
+.. index::
+    single: Event Dispatcher; Immutable
+
+The Immutable Event Dispatcher
+==============================
+
+.. versionadded:: 2.1
+    This feature was added in Symfony 2.1.
+
+The :class:`Symfony\\Component\\EventDispatcher\\ImmutableEventDispatcher` is
+a locked or frozen event dispatcher. The dispatcher cannot register new
+listeners or subscribers.
+
+The ``ImmutableEventDispatcher`` takes another event dispatcher with all the
+listeners and subscribers. The immutable dispatcher is just a proxy of this
+original dispatcher.
+
+To use it, first create a normal dispatcher (``EventDispatcher`` or
+``ContainerAwareEventDispatcher``) and register some listeners or
+subscribers::
+
+    use Symfony\Component\EventDispatcher\EventDispatcher;
+
+    $dispatcher = new EventDispatcher();
+    $dispatcher->addListener('foo.action', function ($event) {
+        // ...
+    });
+
+    // ...
+
+Now, inject that into an ``ImmutableEventDispatcher``::
+
+    use Symfony\Component\EventDispatcher\ImmutableEventDispatcher;
+    // ...
+
+    $immutableDispatcher = new ImmutableEventDispatcher($dispatcher);
+
+You'll need to use this new dispatcher in your project.
+
+If you are trying to execute one of the methods which modifies the dispatcher
+(e.g. ``addListener``), a ``BadMethodCallException`` is thrown.

components/event_dispatcher/index.rst

@@ -5,5 +5,6 @@ Event Dispatcher
     :maxdepth: 2
 
     introduction
-    generic_event
     container_aware_dispatcher
+    generic_event
+    immutable_dispatcher

components/event_dispatcher/introduction.rst

@@ -588,6 +588,15 @@ part of the listener's processing logic::
         }
     }
 
+Other Dispatchers
+-----------------
+
+Besides the commonly used ``EventDispatcher``, the component comes with 2
+other dispatchers:
+
+* :doc:`/components/event_dispatcher/container_aware_dispatcher`
+* :doc:`/components/event_dispatcher/immutable_dispatcher`
+
 .. _Mediator: http://en.wikipedia.org/wiki/Mediator_pattern
 .. _Closures: http://php.net/manual/en/functions.anonymous.php
 .. _PHP callable: http://www.php.net/manual/en/language.pseudo-types.php#language.types.callback

components/map.rst.inc

@@ -51,6 +51,7 @@
   * :doc:`/components/event_dispatcher/introduction`
   * :doc:`/components/event_dispatcher/container_aware_dispatcher`
   * :doc:`/components/event_dispatcher/generic_event`
+  * :doc:`/components/event_dispatcher/immutable_dispatcher`
 
 * **Filesystem**
 

contributing/code/patches.rst

@@ -107,13 +107,13 @@ Choose the right Branch
 Before working on a patch, you must determine on which branch you need to
 work. The branch should be based on the `master` branch if you want to add a
 new feature. But if you want to fix a bug, use the oldest but still maintained
-version of Symfony where the bug happens (like `2.1`).
+version of Symfony where the bug happens (like `2.2`).
 
 .. note::
 
     All bug fixes merged into maintenance branches are also merged into more
     recent branches on a regular basis. For instance, if you submit a patch
-    for the `2.1` branch, the patch will also be applied by the core team on
+    for the `2.2` branch, the patch will also be applied by the core team on
     the `master` branch.
 
 Create a Topic Branch
@@ -126,18 +126,18 @@ topic branch:
 
     $ git checkout -b BRANCH_NAME master
 
-Or, if you want to provide a bugfix for the 2.1 branch, first track the remote
-`2.1` branch locally:
+Or, if you want to provide a bugfix for the 2.2 branch, first track the remote
+`2.2` branch locally:
 
 .. code-block:: bash
 
-    $ git checkout -t origin/2.1
+    $ git checkout -t origin/2.2
 
-Then create a new branch off the 2.1 branch to work on the bugfix:
+Then create a new branch off the 2.2 branch to work on the bugfix:
 
 .. code-block:: bash
 
-    $ git checkout -b BRANCH_NAME 2.1
+    $ git checkout -b BRANCH_NAME 2.2
 
 .. tip::
 
@@ -230,7 +230,7 @@ while to finish your changes):
 
 .. tip::
 
-    Replace `master` with `2.1` if you are working on a bugfix
+    Replace `master` with `2.2` if you are working on a bugfix
 
 When doing the ``rebase`` command, you might have to fix merge conflicts.
 ``git status`` will show you the *unmerged* files. Resolve all the conflicts,
@@ -254,8 +254,8 @@ You can now make a pull request on the ``symfony/symfony`` Github repository.
 
 .. tip::
 
-    Take care to point your pull request towards ``symfony:2.1`` if you want
-    the core team to pull a bugfix based on the 2.1 branch.
+    Take care to point your pull request towards ``symfony:2.2`` if you want
+    the core team to pull a bugfix based on the 2.2 branch.
 
 To ease the core team work, always include the modified components in your
 pull request message, like in:

cookbook/map.rst.inc

@@ -102,6 +102,7 @@
 * :doc:`/cookbook/profiler/index`
 
   * :doc:`/cookbook/profiler/data_collector`
+  * :doc:`/cookbook/profiler/matchers`
 
 * :doc:`/cookbook/request/index`
 

cookbook/profiler/index.rst

@@ -5,3 +5,4 @@ Profiler
     :maxdepth: 2
 
     data_collector
+    matchers