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.
 

book/forms.rst

@@ -11,8 +11,8 @@ learning the most important features of the form library along the way.
 
 .. note::
 
-   The Symfony form component is a standalone library that can be used outside
-   of Symfony2 projects. For more information, see the `Symfony2 Form Component`_
+   The Symfony Form component is a standalone library that can be used outside
+   of Symfony2 projects. For more information, see the `Symfony2 Form component`_
    on Github.
 
 .. index::
@@ -186,7 +186,7 @@ it into a format that's suitable for being rendered in an HTML form.
    The form system is smart enough to access the value of the protected
    ``task`` property via the ``getTask()`` and ``setTask()`` methods on the
    ``Task`` class. Unless a property is public, it *must* have a "getter" and
-   "setter" method so that the form component can get and put data onto the
+   "setter" method so that the Form component can get and put data onto the
    property. For a Boolean property, you can use an "isser" or "hasser" method
    (e.g. ``isPublished()`` or ``hasReminder()``) instead of a getter (e.g.
    ``getPublished()`` or ``getReminder()``).
@@ -420,6 +420,22 @@ corresponding errors printed out with the form.
    but are being prevented by your browser from, for example, submitting
    blank fields.
 
+   .. configuration-block::
+
+       .. code-block:: html+jinja
+
+           {# src/Acme/DemoBundle/Resources/views/Default/new.html.twig #}
+
+           {{ form(form, {'attr': {'novalidate': 'novalidate'}}) }}
+
+       .. code-block:: html+php
+
+           <!-- src/Acme/DemoBundle/Resources/views/Default/new.html.php -->
+
+           <?php echo $view['form']->form($form, array(
+               'attr' => array('novalidate' => 'novalidate'),
+           )) ?>
+
 Validation is a very powerful feature of Symfony2 and has its own
 :doc:`dedicated chapter </book/validation>`.
 
@@ -806,7 +822,9 @@ used the ``form_row`` helper:
                 {{ form_widget(form.dueDate) }}
             </div>
 
-        <input type="submit" />
+            <div>
+                {{ form_widget(form.save) }}
+            </div>
 
         {{ form_end(form) }}
 
@@ -828,7 +846,9 @@ used the ``form_row`` helper:
                 <?php echo $view['form']->widget($form['dueDate']) ?>
             </div>
 
-            <input type="submit" />
+            <div>
+                <?php echo $view['form']->widget($form['save']) ?>
+            </div>
 
         <?php echo $view['form']->end($form) ?>
 
@@ -1193,7 +1213,7 @@ Embedded Forms
 Often, you'll want to build a form that will include fields from many different
 objects. For example, a registration form may contain data belonging to
 a ``User`` object as well as many ``Address`` objects. Fortunately, this
-is easy and natural with the form component.
+is easy and natural with the Form component.
 
 Embedding a Single Object
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1395,7 +1415,7 @@ do this, create a new template file that will store the new markup:
         </div>
 
 The ``form_row`` form fragment is used when rendering most fields via the
-``form_row`` function. To tell the form component to use your new ``form_row``
+``form_row`` function. To tell the Form component to use your new ``form_row``
 fragment defined above, add the following to the top of the template that
 renders the form:
 
@@ -1408,7 +1428,7 @@ renders the form:
 
         {% form_theme form 'AcmeTaskBundle:Form:fields.html.twig' 'AcmeTaskBundle:Form:fields2.html.twig' %}
 
-        {{ form(form) }}
+        <!-- ... render the form -->
 
     .. code-block:: html+php
 
@@ -1417,7 +1437,7 @@ renders the form:
 
         <?php $view['form']->setTheme($form, array('AcmeTaskBundle:Form', 'AcmeTaskBundle:Form')) ?>
 
-        <?php echo $view['form']->form($form) ?>
+        <!-- ... render the form -->
 
 The ``form_theme`` tag (in Twig) "imports" the fragments defined in the given
 template and uses them when rendering the form. In other words, when the
@@ -1455,7 +1475,7 @@ Form Fragment Naming
 ~~~~~~~~~~~~~~~~~~~~
 
 In Symfony, every part of a form that is rendered - HTML form elements, errors,
-labels, etc - is defined in a base theme, which is a collection of blocks
+labels, etc. - is defined in a base theme, which is a collection of blocks
 in Twig and a collection of template files in PHP.
 
 In Twig, every block needed is defined in a single template file (`form_div_layout.html.twig`_)
@@ -1856,7 +1876,7 @@ There's still much more to learn about the powerful world of forms, such as
 how to handle
 :doc:`file uploads with Doctrine </cookbook/doctrine/file_uploads>` or how
 to create a form where a dynamic number of sub-forms can be added (e.g. a
-todo list where you can keep adding more fields via Javascript before submitting).
+todo list where you can keep adding more fields via JavaScript before submitting).
 See the cookbook for these topics. Also, be sure to lean on the
 :doc:`field type reference documentation </reference/forms/types>`, which
 includes examples of how to use each field type and its options.
@@ -1871,7 +1891,7 @@ Learn more from the Cookbook
 * :doc:`/cookbook/form/dynamic_form_modification`
 * :doc:`/cookbook/form/data_transformers`
 
-.. _`Symfony2 Form Component`: https://github.com/symfony/Form
+.. _`Symfony2 Form component`: https://github.com/symfony/Form
 .. _`DateTime`: http://php.net/manual/en/class.datetime.php
 .. _`Twig Bridge`: https://github.com/symfony/symfony/tree/master/src/Symfony/Bridge/Twig
 .. _`form_div_layout.html.twig`: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig

book/from_flat_php_to_symfony2.rst

@@ -247,7 +247,7 @@ the layout:
 You've now introduced a methodology that allows for the reuse of the
 layout. Unfortunately, to accomplish this, you're forced to use a few ugly
 PHP functions (``ob_start()``, ``ob_get_clean()``) in the template. Symfony2
-uses a ``Templating`` component that allows this to be accomplished cleanly
+uses a Templating component that allows this to be accomplished cleanly
 and easily. You'll see it in action shortly.
 
 Adding a Blog "show" Page
@@ -476,12 +476,15 @@ the HTTP response being returned. Use them to improve the blog:
         $response = show_action($request->query->get('id'));
     } else {
         $html = '<html><body><h1>Page Not Found</h1></body></html>';
-        $response = new Response($html, 404);
+        $response = new Response($html, Response::HTTP_NOT_FOUND);
     }
 
     // echo the headers and send the response
     $response->send();
 
+.. versionadded:: 2.4
+    Support for HTTP status code constants was added in Symfony 2.4.
+
 The controllers are now responsible for returning a ``Response`` object.
 To make this easier, you can add a new ``render_template()`` function, which,
 incidentally, acts quite a bit like the Symfony2 templating engine:
@@ -583,7 +586,7 @@ them for you. Here's the same sample application, now built in Symfony2::
     }
 
 The two controllers are still lightweight. Each uses the :doc:`Doctrine ORM library </book/doctrine>`
-to retrieve objects from the database and the ``Templating`` component to
+to retrieve objects from the database and the Templating component to
 render a template and return a ``Response`` object. The list template is
 now quite a bit simpler:
 
@@ -688,7 +691,7 @@ migrating the blog from flat PHP to Symfony2 has improved life:
   Templating, Security, Form, Validation and Translation components (to name
   a few);
 
-* The application now enjoys **fully-flexible URLs** thanks to the ``Routing``
+* The application now enjoys **fully-flexible URLs** thanks to the Routing
   component;
 
 * Symfony2's HTTP-centric architecture gives you access to powerful tools

book/http_cache.rst

@@ -474,7 +474,7 @@ The resulting HTTP header will look like this:
 
 Note that in HTTP versions before 1.1 the origin server wasn't required to
 send the ``Date`` header. Consequently the cache (e.g. the browser) might
-need to rely onto his local clock to evaluate the ``Expires`` header making
+need to rely on the local clock to evaluate the ``Expires`` header making
 the lifetime calculation vulnerable to clock skew. Another limitation
 of the ``Expires`` header is that the specification states that "HTTP/1.1
 servers should not send ``Expires`` dates more than one year in the future."
@@ -535,7 +535,7 @@ example).
     The 304 status code means "Not Modified". It's important because with
     this status code the response does *not* contain the actual content being
     requested. Instead, the response is simply a light-weight set of directions that
-    tell cache that it should use its stored version.
+    tells the cache that it should use its stored version.
 
 Like with expiration, there are two different HTTP headers that can be used
 to implement the validation model: ``ETag`` and ``Last-Modified``.
@@ -1059,15 +1059,18 @@ Here is how you can configure the Symfony2 reverse proxy to support the
 
             $response = new Response();
             if (!$this->getStore()->purge($request->getUri())) {
-                $response->setStatusCode(404, 'Not purged');
+                $response->setStatusCode(Response::HTTP_NOT_FOUND, 'Not purged');
             } else {
-                $response->setStatusCode(200, 'Purged');
+                $response->setStatusCode(Response::HTTP_OK, 'Purged');
             }
 
             return $response;
         }
     }
 
+.. versionadded:: 2.4
+    Support for HTTP status code constants was added in Symfony 2.4.
+
 .. caution::
 
     You must protect the ``PURGE`` HTTP method somehow to avoid random people