Some general grammar and style fixes in the book

Author: frne

book/doctrine.rst

@@ -119,7 +119,7 @@ for you:
 .. sidebar:: Setting up the Database to be UTF8
 
     One mistake even seasoned developers make when starting a Symfony project
-    is forgetting to setup default charset and collation on their database,
+    is forgetting to set up default charset and collation on their database,
     ending up with latin type collations, which are default for most databases.
     They might even remember to do it the very first time, but forget that
     it's all gone after running a relatively common command during development:
@@ -339,7 +339,7 @@ see the :ref:`book-doctrine-field-types` section.
 
     You can also check out Doctrine's `Basic Mapping Documentation`_ for
     all details about mapping information. If you use annotations, you'll
-    need to prepend all annotations with ``ORM\`` (e.g. ``ORM\Column(..)``),
+    need to prepend all annotations with ``ORM\`` (e.g. ``ORM\Column(...)``),
     which is not shown in Doctrine's documentation. You'll also need to include
     the ``use Doctrine\ORM\Mapping as ORM;`` statement, which *imports* the
     ``ORM`` annotations prefix.
@@ -357,7 +357,7 @@ see the :ref:`book-doctrine-field-types` section.
 
 .. note::
 
-    When using another library or program (ie. Doxygen) that uses annotations,
+    When using another library or program (i.e. Doxygen) that uses annotations,
     you should place the ``@IgnoreAnnotation`` annotation on the class to
     indicate which annotations Symfony should ignore.
 
@@ -385,7 +385,7 @@ a regular PHP class, you need to create getter and setter methods (e.g. ``getNam
 
     $ php app/console doctrine:generate:entities AppBundle/Entity/Product
 
-This command makes sure that all of the getters and setters are generated
+This command makes sure that all the getters and setters are generated
 for the ``Product`` class. This is a safe command - you can run it over and
 over again: it only generates getters and setters that don't exist (i.e. it
 doesn't replace your existing methods).
@@ -432,7 +432,7 @@ mapping information) of a bundle or an entire namespace:
 .. note::
 
     Doctrine doesn't care whether your properties are ``protected`` or ``private``,
-    or whether or not you have a getter or setter function for a property.
+    or whether you have a getter or setter function for a property.
     The getters and setters are generated here only because you'll need them
     to interact with your PHP object.
 
@@ -770,7 +770,7 @@ already did in the previous section).
 
 The DQL syntax is incredibly powerful, allowing you to easily join between
 entities (the topic of :ref:`relations <book-doctrine-relations>` will be
-covered later), group, etc. For more information, see the official Doctrine
+covered later), group, etc. For more information, see the official
 `Doctrine Query Language`_ documentation.
 
 Custom Repository Classes
@@ -833,7 +833,7 @@ used earlier to generate the missing getter and setter methods:
     $ php app/console doctrine:generate:entities AppBundle
 
 Next, add a new method - ``findAllOrderedByName()`` - to the newly generated
-repository class. This method will query for all of the ``Product`` entities,
+repository class. This method will query for all the ``Product`` entities,
 ordered alphabetically.
 
 .. code-block:: php
@@ -1352,7 +1352,7 @@ Doctrine's `Lifecycle Events documentation`_.
     transforming data in the entity (e.g. setting a created/updated field,
     generating a slug value).
 
-    If you need to do some heavier lifting - like perform logging or send
+    If you need to do some heavier lifting - like performing logging or sending
     an email - you should register an external class as an event listener
     or subscriber and give it access to whatever resources you need. For
     more information, see :doc:`/cookbook/doctrine/event_listeners_subscribers`.
@@ -1362,7 +1362,7 @@ Doctrine's `Lifecycle Events documentation`_.
 Doctrine Field Types Reference
 ------------------------------
 
-Doctrine comes with a large number of field types available. Each of these
+Doctrine comes with numerous field types available. Each of these
 maps a PHP data type to a specific column type in whatever database you're
 using. For each field type, the ``Column`` can be configured further, setting
 the ``length``, ``nullable`` behavior, ``name`` and other options. To see a

book/forms.rst

@@ -170,7 +170,7 @@ That's it! Just three lines are needed to render the complete form:
 * ``form_start(form)`` - Renders the start tag of the form, including the
   correct enctype attribute when using file uploads;
 
-* ``form_widget(form)`` - Renders all of the fields, which includes the field
+* ``form_widget(form)`` - Renders all the fields, which includes the field
   element itself, a label and any validation error messages for the field;
 
 * ``form_end()`` - Renders the end tag of the form and any fields that have not
@@ -262,7 +262,7 @@ possible paths:
    .. note::
 
        You can use the method :method:`Symfony\\Component\\Form\\FormInterface::isSubmitted`
-       to check whether a form was submitted, regardless of whether or not the
+       to check whether a form was submitted, regardless of whether the
        submitted data is actually valid.
 
 #. When the user submits the form with valid data, the submitted data is again
@@ -330,9 +330,9 @@ Form Validation
 In the previous section, you learned how a form can be submitted with valid
 or invalid data. In Symfony, validation is applied to the underlying object
 (e.g. ``Task``). In other words, the question isn't whether the "form" is
-valid, but whether or not the ``$task`` object is valid after the form has
+valid, but whether the ``$task`` object is valid after the form has
 applied the submitted data to it. Calling ``$form->isValid()`` is a shortcut
-that asks the ``$task`` object whether or not it has valid data.
+that asks the ``$task`` object whether it has valid data.
 
 Validation is done by adding a set of rules (called constraints) to a class. To
 see this in action, add validation constraints so that the ``task`` field cannot
@@ -639,7 +639,7 @@ the documentation for each type.
     option on your field to ``false`` or
     :ref:`disable HTML5 validation <book-forms-html5-validation-disable>`.
 
-    Also note that setting the ``required`` option to ``true`` will **not**
+    Also, note that setting the ``required`` option to ``true`` will **not**
     result in server-side validation to be applied. In other words, if a
     user submits a blank value for the field (either with an old browser
     or web service, for example), it will be accepted as a valid value unless
@@ -1486,7 +1486,7 @@ In Twig, every block needed is defined in a single template file (e.g.
 file, you can see every block needed to render a form and every default field
 type.
 
-In PHP, the fragments are individual template files. By default they are located in
+In PHP, the fragments are individual template files. By default, they are located in
 the `Resources/views/Form` directory of the framework bundle (`view on GitHub`_).
 
 Each fragment name follows the same basic pattern and is broken up into two pieces,

book/from_flat_php_to_symfony2.rst

@@ -126,7 +126,7 @@ is primarily an HTML file that uses a template-like PHP syntax:
         </body>
     </html>
 
-By convention, the file that contains all of the application logic - ``index.php`` -
+By convention, the file that contains all the application logic - ``index.php`` -
 is known as a "controller". The term :term:`controller` is a word you'll hear
 a lot, regardless of the language or framework you use. It refers simply
 to the area of *your* code that processes user input and prepares the response.
@@ -177,7 +177,7 @@ of the application are isolated in a new file called ``model.php``:
 
 .. tip::
 
-   The filename ``model.php`` is used because the logic and data access of
+   The file name ``model.php`` is used because the logic and data access of
    an application is traditionally known as the "model" layer. In a well-organized
    application, the majority of the code representing your "business logic"
    should live in the model (as opposed to living in a controller). And unlike
@@ -244,7 +244,7 @@ the layout:
 
     <?php include 'layout.php' ?>
 
-You've now introduced a methodology that allows for the reuse of the
+You've now introduced a methodology that allows reusing the
 layout. Unfortunately, to accomplish this, you're forced to use a few ugly
 PHP functions (``ob_start()``, ``ob_get_clean()``) in the template. Symfony
 uses a Templating component that allows this to be accomplished cleanly

book/http_cache.rst

@@ -236,7 +236,7 @@ Here is a list of the main options:
     (default: ``60``). This setting is overridden by the ``stale-if-error`` HTTP
     ``Cache-Control`` extension (see RFC 5861).
 
-If ``debug`` is ``true``, Symfony automatically adds a ``X-Symfony-Cache``
+If ``debug`` is ``true``, Symfony automatically adds an ``X-Symfony-Cache``
 header to the response containing useful information about cache hits and
 misses.
 
@@ -427,7 +427,7 @@ on a cache to store and return "fresh" responses.
     model of the specification dominates your work. Unfortunately, the actual
     specification document - `RFC 2616`_ - can be difficult to read.
 
-    There is an on-going effort (`HTTP Bis`_) to rewrite the RFC 2616. It does
+    There is an ongoing effort (`HTTP Bis`_) to rewrite the RFC 2616. It does
     not describe a new version of HTTP, but mostly clarifies the original HTTP
     specification. The organization is also improved as the specification
     is split into seven parts; everything related to HTTP caching can be
@@ -482,7 +482,7 @@ The resulting HTTP header will look like this:
     timezone as required by the specification.
 
 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
+send the ``Date`` header. Consequently, the cache (e.g. the browser) might
 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
@@ -529,7 +529,7 @@ stale.
 
 The validation model addresses this issue. Under this model, the cache continues
 to store responses. The difference is that, for each request, the cache asks
-the application whether or not the cached response is still valid. If the
+the application whether the cached response is still valid. If the
 cache *is* still valid, your application should return a 304 status code
 and no content. This tells the cache that it's ok to return the cached response.
 

book/http_fundamentals.rst

@@ -38,7 +38,7 @@ how you develop on the web, the goal of your server is *always* to understand
 simple text requests, and return simple text responses.
 
 Symfony is built from the ground up around that reality. Whether you realize
-it or not, HTTP is something you use everyday. With Symfony, you'll learn
+it or not, HTTP is something you use every day. With Symfony, you'll learn
 how to master it.
 
 .. index::
@@ -542,7 +542,7 @@ regardless of how your project is developed. To name a few:
 :doc:`Translation </components/translation/introduction>`
     A framework for translating strings in your application.
 
-Each and every one of these components is decoupled and can be used in *any*
+Each one of these components is decoupled and can be used in *any*
 PHP project, regardless of whether or not you use the Symfony framework.
 Every part is made to be used if needed and replaced when necessary.
 

book/installation.rst

@@ -279,7 +279,7 @@ If there are any issues, correct them now before moving on.
 Updating Symfony Applications
 -----------------------------
 
-At this point, you've create a fully-functional Symfony application in which
+At this point, you've created a fully-functional Symfony application in which
 you'll start to develop your own project. A Symfony application depends on
 a number of external libraries. These are downloaded into the ``vendor/`` directory
 and they are managed exclusively by Composer.
@@ -326,10 +326,10 @@ If you're using a version control system like `Git`_, you can safely commit all
 your project's code. The reason is that Symfony applications already contain a
 ``.gitignore`` file specially prepared for Symfony.
 
-For specific instructions on how best to setup your project to be stored
+For specific instructions on how best to set up your project to be stored
 in Git, see :doc:`/cookbook/workflow/new_project_git`.
 
-Checking out a Versioned Symfony Application
+Checking out a versioned Symfony Application
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When using Composer to manage application's dependencies, it's recommended to

book/page_creation.rst

@@ -93,7 +93,7 @@ Before you begin: Create the Bundle
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Before you begin, you'll need to create a *bundle*. In Symfony, a :term:`bundle`
-is like a plugin, except that all of the code in your application will live
+is like a plugin, except that all the code in your application will live
 inside a bundle.
 
 A bundle is nothing more than a directory that houses everything related
@@ -108,7 +108,7 @@ create the route.
 
 To create a bundle called ``AcmeDemoBundle`` (a play bundle that you'll
 build in this chapter), run the following command and follow the on-screen
-instructions (use all of the default options):
+instructions (use all the default options):
 
 .. code-block:: bash
 
@@ -327,7 +327,7 @@ An optional, but common, third step in the process is to create a template.
 Optional Step 3: Create the Template
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Templates allow you to move all of the presentation (e.g. HTML code) into
+Templates allow you to move all the presentation code (e.g. HTML) into
 a separate file and reuse different portions of the page layout. Instead
 of writing the HTML inside the controller, render a template instead:
 
@@ -607,7 +607,7 @@ You'll learn more about each of these directories in later chapters.
 The Source (``src``) Directory
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Put simply, the ``src/`` directory contains all of the actual code (PHP code,
+Put simply, the ``src/`` directory contains all the actual code (PHP code,
 templates, configuration files, stylesheets, etc) that drives *your* application.
 When developing, the vast majority of your work will be done inside one or
 more bundles that you create in this directory.
@@ -788,7 +788,7 @@ bundle.
 Application Configuration
 -------------------------
 
-An application consists of a collection of bundles representing all of the
+An application consists of a collection of bundles representing all the
 features and capabilities of your application. Each bundle can be customized
 via configuration files written in YAML, XML or PHP. By default, the main
 configuration file lives in the ``app/config/`` directory and is called

book/security.rst

@@ -171,7 +171,7 @@ Firewalls (Authentication)
 
 When a user makes a request to a URL that's protected by a firewall, the
 security system is activated. The job of the firewall is to determine whether
-or not the user needs to be authenticated, and if they do, to send a response
+the user needs to be authenticated, and if they do, to send a response
 back to the user initiating the authentication process.
 
 A firewall is activated when the URL of an incoming request matches the configured
@@ -708,7 +708,7 @@ see :doc:`/cookbook/security/form_login`.
     Next, make sure that your ``check_path`` URL (e.g. ``/login_check``)
     is behind the firewall you're using for your form login (in this example,
     the single firewall matches *all* URLs, including ``/login_check``). If
-    ``/login_check`` doesn't match any firewall, you'll receive a ``Unable
+    ``/login_check`` doesn't match any firewall, you'll receive an ``Unable
     to find the controller for path "/login_check"`` exception.
 
     **4. Multiple firewalls don't share security context**
@@ -825,7 +825,7 @@ things:
 ...................
 
 Symfony creates an instance of :class:`Symfony\\Component\\HttpFoundation\\RequestMatcher`
-for each ``access_control`` entry, which determines whether or not a given
+for each ``access_control`` entry, which determines whether a given
 access control should be used on this request. The following ``access_control``
 options are used for matching:
 
@@ -1458,7 +1458,7 @@ key in ``app/config/security.yml``.
 
     When you allow a user to submit a plaintext password (e.g. registration
     form, change password form), you *must* have validation that guarantees
-    that the password is 4096 characters or less. Read more details in
+    that the password is 4096 characters or fewer. Read more details in
     :ref:`How to implement a simple Registration Form <cookbook-registration-password-max>`.
 
 Retrieving the User Object
@@ -1659,7 +1659,7 @@ Roles
 
 The idea of a "role" is key to the authorization process. Each user is assigned
 a set of roles and then each resource requires one or more roles. If the user
-has any one of the required roles, access is granted. Otherwise access is denied.
+has any one of the required roles, access is granted. Otherwise, access is denied.
 
 Roles are pretty simple, and are basically strings that you can invent and
 use as needed (though roles are objects internally). For example, if you
@@ -2062,7 +2062,7 @@ Security can be a deep and complex issue to solve correctly in your application.
 Fortunately, Symfony's Security component follows a well-proven security
 model based around *authentication* and *authorization*. Authentication,
 which always happens first, is handled by a firewall whose job is to determine
-the identity of the user through several different methods (e.g. HTTP authentication,
+the identity of the user through several methods (e.g. HTTP authentication,
 login form, etc). In the cookbook, you'll find examples of other methods
 for handling authentication, including how to implement a "remember me" cookie
 functionality.

book/service_container.rst

@@ -174,7 +174,7 @@ is never created. This saves memory and increases the speed of your application.
 This also means that there's very little or no performance hit for defining
 lots of services. Services that are never used are never constructed.
 
-As an added bonus, the ``Mailer`` service is only created once and the same
+As a bonus, the ``Mailer`` service is only created once and the same
 instance is returned each time you ask for the service. This is almost always
 the behavior you'll need (it's more flexible and powerful), but you'll learn
 later how you can configure a service that has multiple instances in the
@@ -525,7 +525,7 @@ In this case, the extension allows you to customize the ``error_handler``,
 the FrameworkBundle uses the options specified here to define and configure
 the services specific to it. The bundle takes care of creating all the necessary
 ``parameters`` and ``services`` for the service container, while still allowing
-much of the configuration to be easily customized. As an added bonus, most
+much of the configuration to be easily customized. As a bonus, most
 service container extensions are also smart enough to perform validation -
 notifying you of options that are missing or the wrong data type.
 
@@ -964,7 +964,7 @@ console. To show all services and the class for each service, run:
 
     $ php app/console container:debug
 
-By default only public services are shown, but you can also view private services:
+By default, only public services are shown, but you can also view private services:
 
 .. code-block:: bash