dannykopping/Slim — comment on commit 3fdc30d98d5038ec9520420fa6d81ef9de24b8a7
File:  line 0
By codeguy:

Thinking on this some more, as I will continue to do for a few days :) I agree that decoupling the route callable from the app is good, but in your example you're moving the coupling from the callable to the hook. The decoupling should be in both directions. The callable in your example does not know about Slim because it simply returns an array. However, Slim must know about your callable because it decodes the returned response data in the hook callback. Ideally, the route callable should return an object that does not require Slim but Slim will know how to handle it in all situations.

What if the route callable can return a response object? This object would replace the existing response object. This also seems obvious: the callable is returning its response. If you choose to echo content instead, that content will be appended to the existing response object.

$app->get('/foo', function () {
return new Response('Foo!');
});

The response object is responsible for its status, headers, and body. Status and header management may be gotten for free by extending Slim_Http_Response. The response body is more tricky to manage. The current `Slim_Http_Response` class is tightly coupled to its assumption that the response body is a string; this affects the `__construct()`, `write()` and `body()` methods. If I can change the `Slim_Http_Response` class to allow easier extension, this may become a viable solution. An example:

$app->get('/foo.json', function () {
return new JsonResponse(array(
'name' => 'Danny'
));
});

The JSON response object would store the data array internally. My only assumption is that it implements a `finalize()` method that returns an array of (int)status, (iterable)headers, and (string)body. But does this inaccurately mix concerns between the request and the view? A bit, yes. Is this a problem? I'm not sure. Either way, we now have complete decoupling between Slim and the callable because both speak a common interface (the response object) without knowing about each other.

Thoughts?

Josh