From d880aeb9a65be20de02ea40ac9446e2aca3fbb3a Mon Sep 17 00:00:00 2001 From: lubiana Date: Mon, 23 May 2022 22:06:21 +0200 Subject: [PATCH] add small typo and wording improvements to chapters 9 and 10, update name of time service --- 09-dependency-injector.md | 1 - 10-invoker.md | 43 +++++++++++++++++++-------------------- 2 files changed, 21 insertions(+), 23 deletions(-) diff --git a/09-dependency-injector.md b/09-dependency-injector.md index 793fb06..c35b99b 100644 --- a/09-dependency-injector.md +++ b/09-dependency-injector.md @@ -121,7 +121,6 @@ the container-interface. In this class we will configure all services required for our application and make them accessible via the get($id) method. -p Before we can implement the interface we need to install its definition with composer `composer require "psr/container:^1.0"`. now we can create a file with a Class that implements that interface. diff --git a/10-invoker.md b/10-invoker.md index 0ed6b59..4fa49aa 100644 --- a/10-invoker.md +++ b/10-invoker.md @@ -2,13 +2,13 @@ ### Invoker -Currently all our Actions need to implement the RequestHandlerInterface, which forces us to accept the Request as the +Currently, all our Actions need to implement the RequestHandlerInterface, which forces us to accept the Request as the one and only argument to our handle function, but most of the time we only need a few attributes in our Action a long -with some services and not the whole Requestobject with all its various properties. +with some services and not the whole Request object with all its various properties. -If we take our Hello action for example we only need a response object, the time service and the 'name' information from -the request-uri. And as that class only provides one simple method we could easily make that invokable as we alreay named -the class hello and it would be redundant to also call the the method hello. So an updated version of that class could +If we take our Hello action for example we only need a response object, the clock service and the 'name' information from +the request-uri. And as that class only provides one simple method we could easily make that invokable as we already named +the class hello, and it would be redundant to also call the method hello. So an updated version of that class could look like this: ```php @@ -16,17 +16,16 @@ final class Hello { public function __invoke( ResponseInterface $response, - Now $now, - string $name = 'Stranger', + Clock $clock, + string $name = 'Stranger' ): ResponseInterface { - $body = $this->response->getBody(); - $nowString = $now->get()->format('H:i:s'); - - $body->write('Hello ' . $name . '!'); - $body->write(' The Time is ' . $nowString); - return $response - ->withBody($body) + $body = $response->getBody(); + + $body->write('Hello ' . $name . '!
'); + $body->write('The time is: ' . $clock->now()->format('H:i:s')); + + return $response->withBody($body) ->withStatus(200); } } @@ -34,17 +33,17 @@ final class Hello It would also be neat if we could define a classname plus a method as target handler in our routes, or even a short closure function if we want to redirect all requests from '/' to '/hello' because we have not defined a handler for the -rootpath of our application yet. +root path of our application yet. ```php $r->addRoute('GET', '/hello[/{name}]', Hello::class); -$r->addRoute('GET', '/other-route', [Other::class, 'someFunctionName']); +$r->addRoute('GET', '/other-route', [Other::class, 'handle']); $r->addRoute('GET', '/', fn (Response $r) => $r->withStatus(302)->withHeader('Location', '/hello')); ``` -In order to support this crazy route definitions we would need to write a lot of for actually calling the result of the -route dispatcher. If the result is a name of an invokable class we would use the container to create an instance of that -class for us and then use the [reflection api](https://www.php.net/manual/en/book.reflection.php) to figure out what +In order to support this crazy route definitions we would need to write a lot of code for actually calling the result of +the route dispatcher. If the result is a name of an invokable class we would use the container to create an instance of +that class for us and then use the [reflection api](https://www.php.net/manual/en/book.reflection.php) to figure out what arguments the __invoke function has, try to fetch all arguments from the container and then add some more from the router if they are needed and available. The same if we have an array of a class name with a function to call, and for a simple callable we would need to manually use reflection as well to resolve all the arguments. @@ -68,13 +67,13 @@ $response = $container->call($handler, $args); Try to open [localhost:1235/](http://localhost:1235/) in your browser and check if you are getting redirected to '/hello'. But by now you should know that I do not like to depend on specific implementations and the call method is not defined in -the psr/container interface. Therefore we would not be able to use that if we are ever switching to the symfony container +the psr/container interface. Therefore, we would not be able to use that if we are ever switching to the symfony container or any other implementation. Fortunately for us (or me) the PHP-CI container ships that function as its own class that is independent of the specific -container implementation so we could use it with any container that implements the ContainerInterface. And best of all +container implementation, so we could use it with any container that implements the ContainerInterface. And best of all the class ships with its own [Interface](https://github.com/PHP-DI/Invoker/blob/master/src/InvokerInterface.php) that -we could implement if we ever want to write our own implementation or we could write an adapter that uses a different +we could implement if we ever want to write our own implementation, or we could write an adapter that uses a different class that solves the same problem. But for now we are using the solution provided by PHP-DI.