Some more fixes after proofreading

Author: frne

book/from_flat_php_to_symfony2.rst

@@ -177,7 +177,7 @@ of the application are isolated in a new file called ``model.php``:
 
 .. tip::
 
-   The file name ``model.php`` is used because the logic and data access of
+   The filename ``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,8 +244,8 @@ the layout:
 
     <?php include 'layout.php' ?>
 
-You've now introduced a methodology that allows reusing the
-layout. Unfortunately, to accomplish this, you're forced to use a few ugly
+You now have a setup that will allow you to reuse 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
 and easily. You'll see it in action shortly.

book/http_cache.rst

@@ -528,9 +528,9 @@ won't be asked to return the updated response until the cache finally becomes
 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 the cached response is still valid. If the
-cache *is* still valid, your application should return a 304 status code
+to store responses. The difference is that, for each request, the cache asks the 
+application if the cached response is still valid or if it needs to be regenerated. 
+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.
 
 Under this model, you only save CPU if you're able to determine that the

book/validation.rst

@@ -31,7 +31,7 @@ your application::
     }
 
 So far, this is just an ordinary class that serves some purpose inside your
-application. The goal of validation is to tell you whether the data
+application. The goal of validation is to tell you if the data
 of an object is valid. For this to work, you'll configure a list of rules
 (called :ref:`constraints <validation-constraints>`) that the object must
 follow in order to be valid. These rules can be specified via a number of
@@ -112,7 +112,7 @@ Using the ``validator`` Service
 Next, to actually validate an ``Author`` object, use the ``validate`` method
 on the ``validator`` service (class :class:`Symfony\\Component\\Validator\\Validator`).
 The job of the ``validator`` is easy: to read the constraints (i.e. rules)
-of a class and verify whether the data on the object satisfies those
+of a class and verify if the data on the object satisfies those
 constraints. If validation fails, a non-empty list of errors
 (class :class:`Symfony\\Component\\Validator\\ConstraintViolationList`) is
 returned. Take this simple example from inside a controller::
@@ -303,7 +303,7 @@ to its class and then pass it to the ``validator`` service.
 Behind the scenes, a constraint is simply a PHP object that makes an assertive
 statement. In real life, a constraint could be: "The cake must not be burned".
 In Symfony, constraints are similar: they are assertions that a condition
-is true. Given a value, a constraint will tell you whether that value
+is true. Given a value, a constraint will tell you if that value
 adheres to the rules of the constraint.
 
 Supported Constraints