Minor fixes: Typos, Formatting, Notations

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::

book/forms.rst

@@ -1286,7 +1286,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`_)

cookbook/doctrine/event_listeners_subscribers.rst

@@ -157,15 +157,15 @@ entity), you should check for the entity's class type in your method
 Creating the Subscriber Class
 -----------------------------
 
-A doctrine event subscriber must implement the ``Doctrine\Common\EventSubscriber``
+A Doctrine event subscriber must implement the ``Doctrine\Common\EventSubscriber``
 interface and have an event method for each event it subscribes to::
 
     // src/Acme/SearchBundle/EventListener/SearchIndexerSubscriber.php
     namespace Acme\SearchBundle\EventListener;
 
     use Doctrine\Common\EventSubscriber;
     use Doctrine\ORM\Event\LifecycleEventArgs;
-    // for doctrine 2.4: Doctrine\Common\Persistence\Event\LifecycleEventArgs;
+    // for Doctrine 2.4: Doctrine\Common\Persistence\Event\LifecycleEventArgs;
     use Acme\StoreBundle\Entity\Product;
 
     class SearchIndexerSubscriber implements EventSubscriber

cookbook/doctrine/file_uploads.rst

@@ -13,15 +13,15 @@ If you choose to, you can also integrate the file upload into your entity
 lifecycle (i.e. creation, update and removal). In this case, as your entity
 is created, updated, and removed from Doctrine, the file uploading and removal
 processing will take place automatically (without needing to do anything in
-your controller);
+your controller).
 
 To make this work, you'll need to take care of a number of details, which
 will be covered in this cookbook entry.
 
 Basic Setup
 -----------
 
-First, create a simple ``Doctrine`` Entity class to work with::
+First, create a simple Doctrine entity class to work with::
 
     // src/Acme/DemoBundle/Entity/Document.php
     namespace Acme\DemoBundle\Entity;
@@ -454,7 +454,7 @@ call to ``$document->upload()`` should be removed from the controller::
 .. caution::
 
     The ``PreUpdate`` and ``PostUpdate`` callbacks are only triggered if there
-    is a change in one of the entity's field that are persisted. This means
+    is a change in one of the entity's fields that are persisted. This means
     that, by default, if you modify only the ``$file`` property, these events
     will not be triggered, as the property itself is not directly persisted
     via Doctrine. One solution would be to use an ``updated`` field that's

cookbook/doctrine/multiple_entity_managers.rst

@@ -200,7 +200,7 @@ You can now use Doctrine just as you did before - using the ``default`` entity
 manager to persist and fetch entities that it manages and the ``customer``
 entity manager to persist and fetch its entities.
 
-The same applies to repository call::
+The same applies to repository calls::
 
     class UserController extends Controller
     {
@@ -225,3 +225,4 @@ The same applies to repository call::
             ;
         }
     }
+

cookbook/doctrine/registration_form.rst

@@ -90,7 +90,7 @@ the class.
 
 .. sidebar:: Why the 4096 Password Limit?
 
-    Notice that the ``plainPassword`` has a max length of ``4096`` characters.
+    Notice that the ``plainPassword`` field has a max length of 4096 characters.
     For security purposes (`CVE-2013-5750`_), Symfony limits the plain password
     length to 4096 characters when encoding it. Adding this constraint makes
     sure that your form will give a validation error if anyone tries a super-long
@@ -139,8 +139,8 @@ Next, create the form for the ``User`` model::
     }
 
 There are just two fields: ``email`` and ``plainPassword`` (repeated to confirm
-the entered password). The ``data_class`` option tells the form the name of
-data class (i.e. your ``User`` entity).
+the entered password). The ``data_class`` option tells the form the name of the
+underlying data class (i.e. your ``User`` entity).
 
 .. tip::
 
@@ -224,7 +224,7 @@ Next, create the form for this ``Registration`` model::
         }
     }
 
-You don't need to use special method for embedding the ``UserType`` form.
+You don't need to use a special method for embedding the ``UserType`` form.
 A form is a field, too - so you can add this like any other field, with the
 expectation that the ``Registration.user`` property will hold an instance
 of the ``User`` class.
@@ -260,7 +260,7 @@ controller for displaying the registration form::
         }
     }
 
-and its template:
+And its template:
 
 .. code-block:: html+jinja
 
@@ -356,6 +356,8 @@ Update your Database Schema
 Of course, since you've added a ``User`` entity during this tutorial, make
 sure that your database schema has been updated properly:
 
+.. code-block:: bash
+
    $ php app/console doctrine:schema:update --force
 
 That's it! Your form now validates, and allows you to save the ``User``

cookbook/doctrine/reverse_engineering.rst

@@ -167,9 +167,9 @@ entity in the ``BlogComment`` entity class.
 
 .. note::
 
-    If you want to have a ``oneToMany`` relationship, you will need to add
-    it manually into the entity or to the generated ``xml`` or ``yml`` files.
-    Add a section on the specific entities for ``oneToMany`` defining the
+    If you want to have a one-to-many relationship, you will need to add
+    it manually into the entity or to the generated XML or YAML files.
+    Add a section on the specific entities for one-to-many defining the
     ``inversedBy`` and the ``mappedBy`` pieces.
 
 The generated entities are now ready to be used. Have fun!

cookbook/form/form_collections.rst

@@ -560,7 +560,7 @@ we talk about next!).
             }
         }
 
-    If you have a ``OneToMany`` relationship, then the workaround is similar,
+    If you have a one-to-many relationship, then the workaround is similar,
     except that you can simply call ``setTask`` from inside ``addTag``.
 
 .. _cookbook-form-collections-remove:
@@ -657,11 +657,11 @@ the relationship between the removed ``Tag`` and ``Task`` object.
     ``Tag`` is properly removed.
 
     In Doctrine, you have two side of the relationship: the owning side and the
-    inverse side. Normally in this case you'll have a ``ManyToMany`` relation
+    inverse side. Normally in this case you'll have a many-to-many relation
     and the deleted tags will disappear and persist correctly (adding new
     tags also works effortlessly).
 
-    But if you have an ``OneToMany`` relation or a ``ManyToMany`` with a
+    But if you have an one-to-many relation or a many-to-many with a
     ``mappedBy`` on the Task entity (meaning Task is the "inverse" side),
     you'll need to do more work for the removed tags to persist correctly.
 
@@ -709,7 +709,7 @@ the relationship between the removed ``Tag`` and ``Task`` object.
                         // remove the Task from the Tag
                         $tag->getTasks()->removeElement($task);
 
-                        // if it were a ManyToOne relationship, remove the relationship like this
+                        // if it were a many-to-one relationship, remove the relationship like this
                         // $tag->setTask(null);
 
                         $em->persist($tag);
@@ -730,7 +730,7 @@ the relationship between the removed ``Tag`` and ``Task`` object.
         }
 
     As you can see, adding and removing the elements correctly can be tricky.
-    Unless you have a ManyToMany relationship where Task is the "owning" side,
+    Unless you have a many-to-many relationship where Task is the "owning" side,
     you'll need to do extra work to make sure that the relationship is properly
     updated (whether you're adding new tags or removing existing tags) on
     each Tag object itself.

cookbook/symfony1.rst

@@ -63,7 +63,7 @@ places.
 In Symfony2, life is much simpler because *all* Symfony2 code must live in
 a bundle. In the pretend symfony1 project, all the code *could* be moved
 into one or more plugins (which is a very good practice, in fact). Assuming
-that all modules, PHP classes, schema, routing configuration, etc were moved
+that all modules, PHP classes, schema, routing configuration, etc. were moved
 into a plugin, the symfony1 ``plugins/`` directory would be very similar
 to the Symfony2 ``src/`` directory.
 
@@ -176,8 +176,8 @@ from specific directories without defining a dependency:
 
 This means that if a class is not found in the ``vendor`` directory, Composer
 will search in the ``src`` directory before throwing a "class does not exist"
-exception. Read more about configuring the Composer Autoloader in
-`the Composer documentation`_
+exception. Read more about configuring the Composer autoloader in
+`the Composer documentation`_.
 
 Using the Console
 -----------------

cookbook/testing/database.rst

@@ -18,7 +18,7 @@ your test always has the same data to work with.
 Mocking the ``Repository`` in a Unit Test
 -----------------------------------------
 
-If you want to test code which depends on a doctrine ``Repository`` in isolation,
+If you want to test code which depends on a Doctrine repository in isolation,
 you need to mock the ``Repository``. Normally you inject the ``EntityManager``
 into your class and use it to get the repository. This makes things a little
 more difficult as you need to mock both the ``EntityManager`` and your repository
@@ -27,7 +27,7 @@ class.
 .. tip::
 
     It is possible (and a good idea) to inject your repository directly by
-    registering your repository as a :doc:`factory service </components/dependency_injection/factories>`
+    registering your repository as a :doc:`factory service </components/dependency_injection/factories>`.
     This is a little bit more work to setup, but makes testing easier as you
     only need to mock the repository.
 

cookbook/web_services/php_soap_extension.rst

@@ -118,7 +118,7 @@ buffering the STDOUT and use ``ob_get_clean()`` to dump the echoed output
 into the content of the Response and clear the output buffer. Finally, you're
 ready to return the ``Response``.
 
-Below is an example calling the service using `NuSOAP`_ client. This example
+Below is an example calling the service using a `NuSOAP`_ client. This example
 assumes that the ``indexAction`` in the controller above is accessible via the
 route ``/soap``::