be keen to newcomers

Author: OskarStark

create_framework/dependency_injection.rst

@@ -66,15 +66,15 @@ framework more configurable, but at the same time, it introduces a lot of
 issues:
 
 * We are not able to register custom listeners anymore as the dispatcher is
-  not available outside the Framework class (an easy workaround could be the
+  not available outside the Framework class (an workaround could be the
   adding of a ``Framework::getEventDispatcher()`` method);
 
 * We have lost the flexibility we had before; you cannot change the
   implementation of the ``UrlMatcher`` or of the ``ControllerResolver``
   anymore;
 
-* Related to the previous point, we cannot test our framework easily anymore
-  as it's impossible to mock internal objects;
+* Related to the previous point, we cannot test our framework without much
+  effort anymore as it's impossible to mock internal objects;
 
 * We cannot change the charset passed to ``ResponseListener`` anymore (a
   workaround could be to pass it as a constructor argument).

create_framework/event_dispatcher.rst

@@ -3,8 +3,7 @@ The EventDispatcher Component
 
 Our framework is still missing a major characteristic of any good framework:
 *extensibility*. Being extensible means that the developer should be able to
-easily hook into the framework life cycle to modify the way the request is
-handled.
+hook into the framework life cycle to modify the way the request is handled.
 
 What kind of hooks are we talking about? Authentication or caching for
 instance. To be flexible, hooks must be plug-and-play; the ones you "register"

create_framework/front_controller.rst

@@ -61,8 +61,8 @@ which name is exposed to the end user via the URL
 (``http://127.0.0.1:4321/bye.php``): there is a direct mapping between the PHP
 script name and the client URL. This is because the dispatching of the request
 is done by the web server directly. It might be a good idea to move this
-dispatching to our code for better flexibility. This can be easily achieved by
-routing all client requests to a single PHP script.
+dispatching to our code for better flexibility. This can be achieved byrouting
+all client requests to a single PHP script.
 
 .. tip::
 

create_framework/http_kernel_httpkernel_class.rst

@@ -4,7 +4,7 @@ The HttpKernel Component: The HttpKernel Class
 If you were to use our framework right now, you would probably have to add
 support for custom error messages. We do have 404 and 500 error support but
 the responses are hardcoded in the framework itself. Making them customizable
-is easy enough though: dispatch a new event and listen to it. Doing it right
+is straightforward though: dispatch a new event and listen to it. Doing it right
 means that the listener has to call a regular controller. But what if the
 error controller throws an exception? You will end up in an infinite loop.
 There should be an easier way, right?
@@ -114,9 +114,8 @@ client; that's what the ``ResponseListener`` does::
 
     $dispatcher->addSubscriber(new HttpKernel\EventListener\ResponseListener('UTF-8'));
 
-This one was easy too! Let's take another one: do you want out of the box
-support for streamed responses? Just subscribe to
-``StreamedResponseListener``::
+If you want out of the box support for streamed responses, subscribe
+to ``StreamedResponseListener``::
 
     $dispatcher->addSubscriber(new HttpKernel\EventListener\StreamedResponseListener());
 

create_framework/routing.rst

@@ -189,7 +189,7 @@ more flexible than the previous one. Enjoy!
 Using the Routing component has one big additional benefit: the ability to
 generate URLs based on Route definitions. When using both URL matching and URL
 generation in your code, changing the URL patterns should have no other
-impact. Want to know how to use the generator? Insanely easy::
+impact. You can use the generator this way::
 
     use Symfony\Component\Routing;
 

create_framework/unit_testing.rst

@@ -136,7 +136,7 @@ Executing this test is as simple as running ``phpunit`` from the
 After the test ran, you should see a green bar. If not, you have a bug
 either in the test or in the framework code!
 
-Adding a unit test for any exception thrown in a controller is just as easy::
+Adding a unit test for any exception thrown in a controller::
 
     public function testErrorHandling()
     {

http_cache.rst

@@ -77,9 +77,8 @@ but is a great way to start.
 
     For details on setting up Varnish, see :doc:`/http_cache/varnish`.
 
-Enabling the proxy is easy: each application comes with a caching kernel (``AppCache``)
-that wraps the default one (``AppKernel``). The caching Kernel *is* the reverse
-proxy.
+Each application comes with a caching kernel (``AppCache``)that wraps the
+default one (``AppKernel``). The caching Kernel *is* the reverse proxy.
 
 To enable caching, modify the code of your front controller. You can also make these
 changes to ``app_dev.php`` to add caching to the ``dev`` environment::
@@ -267,7 +266,7 @@ Validation Caching
    single: Cache; Cache-Control header
    single: HTTP headers; Cache-Control
 
-With expiration caching, you simply say "cache for 3600 seconds!". But, when someone
+With expiration caching, you say "cache for 3600 seconds!". But, when someone
 updates cached content, you won't see that content on your site until the cache
 expires.
 

security.rst

@@ -452,7 +452,7 @@ this would deny you access. More on that later (:ref:`security-authorization-acc
 Loading Users from the Database
 ...............................
 
-If you'd like to load your users via the Doctrine ORM, that's easy! See
+If you'd like to load your users via the Doctrine ORM, see
 :doc:`/security/entity_provider` for all the details.
 
 .. _security-encoding-user-password:
@@ -685,8 +685,7 @@ Add Code to Deny Access
 There are **two** ways to deny access to something:
 
 #. :ref:`access_control in security.yml <security-authorization-access-control>`
-   allows you to protect URL patterns (e.g. ``/admin/*``). This is easy,
-   but less flexible;
+   allows you to protect URL patterns (e.g. ``/admin/*``). Simpler, but less flexible;
 
 #. :ref:`in your code via the security.authorization_checker service <security-securing-controller>`.
 
@@ -808,8 +807,8 @@ matches the URL.
         ]);
 
 Prepending the path with ``^`` means that only URLs *beginning* with the
-pattern are matched. For example, a path of simply ``/admin`` (without
-the ``^``) would match ``/admin/foo`` but would also match URLs like ``/foo/admin``.
+pattern are matched. For example, a path of ``/admin`` (without the ``^``)
+would match ``/admin/foo`` but would also match URLs like ``/foo/admin``.
 
 .. _security-access-control-explanation:
 
@@ -828,7 +827,7 @@ the ``^``) would match ``/admin/foo`` but would also match URLs like ``/foo/admi
 Securing Controllers and other Code
 ...................................
 
-You can easily deny access from inside a controller::
+You can deny access from inside a controller::
 
     // ...
 

session/php_bridge.rst

@@ -45,7 +45,7 @@ for the ``handler_id``:
             ],
         ]);
 
-Otherwise, if the problem is simply that you cannot avoid the application
+Otherwise, if the problem is that you cannot avoid the application
 starting the session with ``session_start()``, you can still make use of
 a Symfony based session save handler by specifying the save handler as in
 the example below: