Documentation Slim vs actual state of code

Hi I’m just looking into Slim Framework, version 3.
I use the skeleton to get started. In the router.php i found this code
return $this->renderer->render($response, 'index.phtml', $args);
This works. However in the Slim docs i found this:
return $this->view->render($response, 'profile.html', ['name' => $args['name']]);
If i use this->view instead of $this->renderer I get an error (view is not valid). But i can’t find $this->renderer anywhere in de docs. So am I looking at the wrong documentation, perhaps?

In the template and alternatively in the router, i try to use the $response object to set a status. But it doesn’t know the response object in both places. The documentation states i should be able to use it. So again, my guess is, I’m using the wrong documentation. Or maybe the documentation is not modified to reflect the latest version?

So, here’s the link to the dos i use: http://www.slimframework.com/docs/
And the link to the skeleton i use: https://github.com/slimphp/Slim-Skeleton
Can anyone tell me if I missed something?

Hi!

Slim-Skeleton injects templating engine to controller with name “renderer”, while docs do it with name “view”, so you need to call your dependency with the same name you use for injecting it. You can use any name you want.

Docs:

$container[‘view’] = function…

So you will call it:

$this->view->…

Slim-Skeleton:

$container[‘renderer’] = function…

So you will call it:

$this->renderer->…

About $response: you are not supposed to call it at all inside views, but in the router absolutely yes. To do that, you need to let router know that you need to access response:

$app->get(‘/’, function ($request, $response, $args) {
return $this->view($response, ‘home.twig’);
});

Thanks, really appreciated. That helpt in understanding whats goin on! I found that in /src/dependencies. Going to read up on this dependencie thing.
About the $response: So how do i set the correct response status code? In the doc it just says:

You can copy a PSR 7 Response object and assign a new status code like this:
$newResponse = $response->withStatus(302);

But why would i want to copy it? I just want to set the correct header in the response thats being send back to the client. For this i need access to the response object. I would expect something along the lines of:

$response->setStatusCode(302);

But the $response variable does’t seem to be present and there’s no setter (as far as the docs are concerned. Or should i perhaps raise an exception in the code that handles my request (this is not a web app, it’s a web based api on a database). Or perhaps php header()?
In Slim 2 I used to write $app->response()->status(302); or $app->halt(400, '....'); but that seems no longer possible.
Any thoughts on this?

You don’t need to copy response, but you can, sometimes that makes code cleaner.

You can set status code with view like this:

$app->get(‘/’, function ($request, $response, $args) {
return $this->view($response->withStatus(302), ‘home.twig’);
});

Or you can do this for example:

$app->get(‘/’, function ($request, $response, $args) {
return $c[‘response’]
->withStatus(404)
->withHeader(‘Content-Type’, ‘text/html’)
->write(‘Page not found’);
});

That would be to early. Only after execution of “home.twig” do i know which status code should be returned to the client.
Perhaps I built my application logic wrongly?
router -> execution of application logic -> response
So the router needs to wait for the application logic to know what to return (maybe 400-ish if the user requested a resource to be updated but he has unsufficient rights, or maybe there’s a wrong CRC in the request). Can i hold off the request until i know what to return?
(Sorry, I’m new to the framework and the docu isn’t very helpful :blush: )

Well you should have no application logic inside view (Twig in this case). All validation, user authorizatien etc. has to happen before calling view, then you can call the view with any status code based on previous actions.

When you execute your view, you cannot change the status code (header) anymore, and you should have no reasen to do that anyway.

Seems middleware is the answer. I’m dabbeling with it and it looks like it holds the clues to the puzzle. Thanks for the help @RikuS!