-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
[4.x] Use callable resolver in the error handler to resolve error renderers #2737
[4.x] Use callable resolver in the error handler to resolve error renderers #2737
Conversation
Travis failed because of the property |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slim/Slim/Handlers/ErrorHandler.php
Lines 222 to 232 in b8eb545
if ($renderer !== null | |
&& ( | |
(is_string($renderer) && !class_exists($renderer)) | |
|| !in_array(ErrorRendererInterface::class, class_implements($renderer), true) | |
) | |
) { | |
throw new RuntimeException( | |
'Non compliant error renderer provided (%s). ' . | |
'Renderer must implement the ErrorRendererInterface' | |
); | |
} |
We can remove that entire logic block since CallableResolver
does all the logic here. All we care about is that a callable is being returned. It will throw an exception if a callable can't be resolved.
I also wonder if we should change the ErrorRendererInterface
to use __invoke()
instead of render()
which would enable us to remove the extra logic added to CallableResolver
. What do you think?
Yes, let's rename |
…//github.com/adriansuter/Slim into feature-customErrorRenderer-callableResolver
The test case is no longer needed, as the error renderers are now directly invokable.
This mock is no longer needed
CAUTIONAs noted in the description of this PR, #2737 (comment), there are some breaking changes:
|
`$renderer` is always caallable.
`$renderer` is always callable.
…//github.com/adriansuter/Slim into feature-customErrorRenderer-callableResolver
This PR is a follow-up of #2734 and addresses #2731.
CAUTION
There are some breaking changes in this PR.
knownContentTypes
of\Slim\Handlers\ErrorHandler
had been removed.\Slim\Handlers\ErrorHandler
changed its signature.Notes
The
\Slim\CallableResolver::resolve()
method had to be changed as well, as the "callable method" of the error renderer interface is calledrender
.Description
A user can register custom error renderers in the following ways:
1. Register a class name
Create a new class implementing the
\Slim\Interfaces\ErrorRendererInterface
, and then simply register the fully qualified class name.2. Register an instance of an error renderer interface
Create a new class like in the example above. Instantiate the class and register the instance.
This is the way to go, if you need to inject objects into your custom error renderer.
3. Closure
Register a closure.
Open questions
I think we could remove (make
private
) the property\Slim\Handlers\ErrorHandler::$renderer
. This was formerly used to override the renderer. As that can be achieved by the technique described above, the property should be removed. Maybe that would be another breaking change?Is there a reason for determining the renderer in the
__invoke()
method of the error handler? If not, I suggest to determine the renderer directly in the\Slim\Handlers\ErrorHandler::respond()
method. Then we can actually get rid of the$renderer
property.