-
Notifications
You must be signed in to change notification settings - Fork 196
Mark deprecated functionality #429
Mark deprecated functionality #429
Conversation
All methods are deprecated starting in 1.1, to be removed in version 2.0. These include: - pipeErrorHandler - routeMiddleware - dispatchMiddleware - getFinalHandler This patch also provides the method `getDefaultDelegate()`, which is used in version 2.0, to allow consumers of `getFinalHandler()` to update their code prior to migrating.
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.
LGTM
* removed in Stratigility 2.0. You can start using standard middleware | ||
* for error handling by calling `raiseThrowables()` on the `Application` | ||
* instance, and piping such middleware in an outer layer of your application. | ||
* For an example, see `Zend\Stratigility\Middleware\ErrorHandler`. |
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.
{@see Zend\Stratigility\Middleware\ErrorHandler}
?
* | ||
* @return callable|null | ||
*/ | ||
public function getDefaultDelegate() |
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.
Why do we need to expose a getter for final handler after all?
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.
It's used internally to lazy-load it when required and none was injected during instantiation, which makes it a canonical source for locating it if the service is not defined.
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.
I see, but it does not need to be public, no?
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.
Again, it becomes the canonical source for the service if no service is registered in the container. As such, if you need access to it for any reason (e.g., to re-use it elsewhere), it would need to be public.
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.
mhmm, sorry but it's not clear to me why would someone want to re-use it outside of Application
context. Any example? 🤔
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.
Sure: you could be nesting an application within another, and want to re-use the default delegate from the parent application. As such, you might build the factory like this:
use Zend\Expressive\AppFactory;
use Zend\Expressive\Application;
use Zend\Expressive\Router\FastRouteRouter;
function ($container)
{
$app = $container->get(Application::class);
$nested = new Application(
new FastRouteRouter(),
$container,
$app->getDefaultDelegate()
);
/* pipe and/or route some middleware */
$nested->pipe(/* ... */);
$nested->get('/subpath', /* ... */);
return $nested;
}
In normal circumstances, if this were dispatched, if a call to $next()
/$delegate->process()
occurs but the pipeline is exhausted, this would return handling to the parent, which might lead to execution later down the stack. By passing the default delegate in, we ensure that this nested application then becomes terminal; once it is dispatched, it must return a response, ensuring no deeper layers are executed.
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.
Haa, thanks for clarifying! These fallback services would be a lot easier if Expressive could provide its default container config that people could override, but unfortunately it would not work with all container interop implementations. 😕
Since we are calling `raiseThrowables()`, we need a 1.3 release.
Final handlers will be removed in version 2.0, to be replaced with default delegates.
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.
Looks good to me.
Forward port #429 Conflicts: CHANGELOG.md composer.json composer.lock src/Application.php src/Container/Exception/InvalidArgumentException.php src/Container/Exception/NotFoundException.php src/Container/TemplatedErrorHandlerFactory.php src/Container/WhoopsErrorHandlerFactory.php src/ErrorMiddlewarePipe.php src/TemplatedErrorHandler.php src/WhoopsErrorHandler.php
This patch marks a number of methods and classes as deprecated for an upcoming 1.1.0 version, based on features proposed in #428. These include:
Application::pipeErrorHandler()
Application::routeMiddleware()
Application::dispatchMiddleware()
Application::getFinalHandler()
(this patch providesgetDefaultDelegate()
as a forwards-compatibility measure)Container\InvalidArgumentException
Container\NotFoundException
Container\TemplatedErrorHandlerFactory
Container\WhoopsErrorHandlerFactory
ErrorMiddlewarePipe
TemplatedErrorHandler
WhoopsErrorHandler
Do not merge until #428 is accepted to develop.