Merge branch 'master' into eom-2-2

Conflicts:
	book/security.rst
	components/property_access/introduction.rst
	components/stopwatch.rst
	cookbook/templating/namespaced_paths.rst
	reference/twig_reference.rst

Author: weaverryan

book/controller.rst

@@ -236,7 +236,7 @@ example:
 
         # app/config/routing.yml
         hello:
-            path:      /hello/{first_name}/{last_name}
+            path:      /hello/{firstName}/{lastName}
             defaults:  { _controller: AcmeHelloBundle:Hello:index, color: green }
 
     .. code-block:: xml
@@ -248,7 +248,7 @@ example:
             xsi:schemaLocation="http://symfony.com/schema/routing
                 http://symfony.com/schema/routing/routing-1.0.xsd">
 
-            <route id="hello" path="/hello/{first_name}/{last_name}">
+            <route id="hello" path="/hello/{firstName}/{lastName}">
                 <default key="_controller">AcmeHelloBundle:Hello:index</default>
                 <default key="color">green</default>
             </route>
@@ -257,19 +257,19 @@ example:
     .. code-block:: php
 
         // app/config/routing.php
-        $collection->add('hello', new Route('/hello/{first_name}/{last_name}', array(
+        $collection->add('hello', new Route('/hello/{firstName}/{lastName}', array(
             '_controller' => 'AcmeHelloBundle:Hello:index',
             'color'       => 'green',
         )));
 
 The controller for this can take several arguments::
 
-    public function indexAction($first_name, $last_name, $color)
+    public function indexAction($firstName, $lastName, $color)
     {
         // ...
     }
 
-Notice that both placeholder variables (``{first_name}``, ``{last_name}``)
+Notice that both placeholder variables (``{firstName}``, ``{lastName}``)
 as well as the default ``color`` variable are available as arguments in the
 controller. When a route is matched, the placeholder variables are merged
 with the ``defaults`` to make one array that's available to your controller.
@@ -281,11 +281,11 @@ the following guidelines in mind while you develop.
 
     Symfony is able to match the parameter names from the route to the variable
     names in the controller method's signature. In other words, it realizes that
-    the ``{last_name}`` parameter matches up with the ``$last_name`` argument.
+    the ``{lastName}`` parameter matches up with the ``$lastName`` argument.
     The arguments of the controller could be totally reordered and still work
     perfectly::
 
-        public function indexAction($last_name, $color, $first_name)
+        public function indexAction($lastName, $color, $firstName)
         {
             // ...
         }
@@ -295,25 +295,25 @@ the following guidelines in mind while you develop.
     The following would throw a ``RuntimeException`` because there is no ``foo``
     parameter defined in the route::
 
-        public function indexAction($first_name, $last_name, $color, $foo)
+        public function indexAction($firstName, $lastName, $color, $foo)
         {
             // ...
         }
 
     Making the argument optional, however, is perfectly ok. The following
     example would not throw an exception::
 
-        public function indexAction($first_name, $last_name, $color, $foo = 'bar')
+        public function indexAction($firstName, $lastName, $color, $foo = 'bar')
         {
             // ...
         }
 
 * **Not all routing parameters need to be arguments on your controller**
 
-    If, for example, the ``last_name`` weren't important for your controller,
+    If, for example, the ``lastName`` weren't important for your controller,
     you could omit it entirely::
 
-        public function indexAction($first_name, $color)
+        public function indexAction($firstName, $color)
         {
             // ...
         }
@@ -501,9 +501,9 @@ value to each variable.
     directly by duplicating the current request. When this
     :ref:`sub request <http-kernel-sub-requests>` is executed via the ``http_kernel``
     service the ``HttpKernel`` returns a ``Response`` object::
-    
+
         use Symfony\Component\HttpKernel\HttpKernelInterface;
-    
+
         $path = array(
             '_controller' => 'AcmeHelloBundle:Hello:fancy',
             'name'        => $name,
@@ -750,12 +750,15 @@ headers and content that's sent back to the client::
     use Symfony\Component\HttpFoundation\Response;
 
     // create a simple Response with a 200 status code (the default)
-    $response = new Response('Hello '.$name, 200);
+    $response = new Response('Hello '.$name, Response::HTTP_OK);
 
     // create a JSON-response with a 200 status code
     $response = new Response(json_encode(array('name' => $name)));
     $response->headers->set('Content-Type', 'application/json');
 
+.. versionadded:: 2.4
+    Support for HTTP status code constants was added in Symfony 2.4.
+
 .. tip::
 
     The ``headers`` property is a

book/doctrine.rst

@@ -1087,7 +1087,7 @@ in a way that makes sense for your needs. The fact that the data needs to
 be persisted to a database is always secondary.
 
 Now, look at the metadata above the ``$category`` property on the ``Product``
-class. The information here tells doctrine that the related class is ``Category``
+class. The information here tells Doctrine that the related class is ``Category``
 and that it should store the ``id`` of the category record on a ``category_id``
 field that lives on the ``product`` table. In other words, the related ``Category``
 object will be stored on the ``$category`` property, but behind the scenes,
@@ -1285,7 +1285,7 @@ More Information on Associations
 
 This section has been an introduction to one common type of entity relationship,
 the one-to-many relationship. For more advanced details and examples of how
-to use other types of relations (e.g. ``one-to-one``, ``many-to-many``), see
+to use other types of relations (e.g. one-to-one, many-to-many), see
 Doctrine's `Association Mapping Documentation`_.
 
 .. note::
@@ -1441,12 +1441,19 @@ using. The following types are supported in Doctrine:
   * ``date``
   * ``time``
   * ``datetime``
+  * ``datetimetz``
 
 * **Other Types**
 
   * ``boolean``
   * ``object`` (serialized and stored in a ``CLOB`` field)
   * ``array`` (serialized and stored in a ``CLOB`` field)
+  * ``blob`` (mapped to a resource stream)
+  * ``simple_array`` (serialized using :phpfunction:`implode()` and :phpfunction:`explode()`,
+    with a comma as delimiter, and stored in a ``CLOB`` field)
+  * ``json_array`` (serialized using :phpfunction:`json_encode()` and :phpfunction:`json_decode()`,
+    and stored in a ``CLOB`` field)
+  * ``guid``
 
 For more information, see Doctrine's `Mapping Types documentation`_.
 
@@ -1483,7 +1490,7 @@ and ``nullable``. Take a few examples:
         fields:
             # A string field length 255 that cannot be null
             # (reflecting the default values for the "length" and *nullable* options)
-            # type attribute is necessary in yaml definitions
+            # type attribute is necessary in YAML definitions
             name:
                 type: string
 
@@ -1500,7 +1507,7 @@ and ``nullable``. Take a few examples:
         <!--
             A string field length 255 that cannot be null
             (reflecting the default values for the "length" and *nullable* options)
-            type attribute is necessary in xml definitions
+            type attribute is necessary in XML definitions
         -->
         <field name="name" type="string" />
         <field name="email"
@@ -1562,7 +1569,7 @@ Some notable or interesting tasks include:
 .. note::
 
    To be able to load data fixtures to your database, you will need to have
-   the ``DoctrineFixturesBundle`` bundle installed. To learn how to do it,
+   the DoctrineFixturesBundle bundle installed. To learn how to do it,
    read the ":doc:`/bundles/DoctrineFixturesBundle/index`" entry of the
    documentation.