Skip to content

spotted minor EN mistakes and coherence issues between the different … #14496

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 30, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion create_framework/dependency_injection.rst
Original file line number Diff line number Diff line change
Expand Up @@ -205,7 +205,7 @@ Now, here is how you can register a custom listener in the front controller::
->addMethodCall('addSubscriber', [new Reference('listener.string_response')])
;

Beside describing your objects, the dependency injection container can also be
Besides describing your objects, the dependency injection container can also be
configured via parameters. Let's create one that defines if we are in debug
mode or not::

Expand Down
2 changes: 1 addition & 1 deletion create_framework/event_dispatcher.rst
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ version of this pattern:
How does it work? The *dispatcher*, the central object of the event dispatcher
system, notifies *listeners* of an *event* dispatched to it. Put another way:
your code dispatches an event to the dispatcher, the dispatcher notifies all
registered listeners for the event, and each listener do whatever it wants
registered listeners for the event, and each listener does whatever it wants
with the event.

As an example, let's create a listener that transparently adds the Google
Expand Down
2 changes: 1 addition & 1 deletion create_framework/front_controller.rst
Original file line number Diff line number Diff line change
Expand Up @@ -132,7 +132,7 @@ its sub-directories (only if needed -- see above tip).
like ``$request = Request::create('/hello?name=Fabien');`` where the
argument is the URL path you want to simulate.

Now that the web server always access the same script (``front.php``) for all
Now that the web server always accesses the same script (``front.php``) for all
pages, we can secure the code further by moving all other PHP files outside the
web root directory:

Expand Down
4 changes: 2 additions & 2 deletions create_framework/http_foundation.rst
Original file line number Diff line number Diff line change
Expand Up @@ -273,7 +273,7 @@ cases by yourself. Why not using a technology that already works?
a look at the ``Symfony\Component\HttpFoundation`` API or read
its dedicated :doc:`documentation </components/http_foundation>`.

Believe or not but we have our first framework. You can stop now if you want.
Believe it or not but we have our first framework. You can stop now if you want.
Using just the Symfony HttpFoundation component already allows you to write
better and more testable code. It also allows you to write code faster as many
day-to-day problems have already been solved for you.
Expand All @@ -282,7 +282,7 @@ As a matter of fact, projects like Drupal have adopted the HttpFoundation
component; if it works for them, it will probably work for you. Don't reinvent
the wheel.

I've almost forgot to talk about one added benefit: using the HttpFoundation
I've almost forgotten to talk about one added benefit: using the HttpFoundation
component is the start of better interoperability between all frameworks and
`applications using it`_ (like `Symfony`_, `Drupal 8`_, `phpBB 3`_, `Laravel`_
and `ezPublish 5`_, and `more`_).
Expand Down
2 changes: 1 addition & 1 deletion create_framework/http_kernel_controller_resolver.rst
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ The move is pretty straightforward and makes a lot of sense as soon as you
create more pages but you might have noticed a non-desirable side effect...
The ``LeapYearController`` class is *always* instantiated, even if the
requested URL does not match the ``leap_year`` route. This is bad for one main
reason: performance wise, all controllers for all routes must now be
reason: performance-wise, all controllers for all routes must now be
instantiated for every request. It would be better if controllers were
lazy-loaded so that only the controller associated with the matched route is
instantiated.
Expand Down
7 changes: 4 additions & 3 deletions create_framework/http_kernel_httpkernelinterface.rst
Original file line number Diff line number Diff line change
Expand Up @@ -46,8 +46,8 @@ Update your framework so that it implements this interface::
}
}

Even if this change looks not too complex, it brings us a lot! Let's talk about one of
the most impressive one: transparent :doc:`HTTP caching </http_cache>` support.
With this change, a little goes a long way! Let's talk about one of
the most impressive upsides: transparent :doc:`HTTP caching </http_cache>` support.

The ``HttpCache`` class implements a fully-featured reverse proxy, written in
PHP; it implements ``HttpKernelInterface`` and wraps another
Expand All @@ -64,7 +64,8 @@ PHP; it implements ``HttpKernelInterface`` and wraps another
new HttpKernel\HttpCache\Store(__DIR__.'/../cache')
);

$framework->handle($request)->send();
$response = $framework->handle($request);
$response->send();

That's all it takes to add HTTP caching support to our framework. Isn't it
amazing?
Expand Down