Closed geerteltink closed 6 years ago
I believe some of them are there only to make migration (from v2 to v3) easier.
We used these classes before, and now we define aliases only. For example see:
https://github.com/zendframework/zend-expressive/blob/master/docs/book/features/container/factories.md
(this is at least about Delegate\DefaultDelegate
)
I can vouch for each, and I'll explain them.
The aliases (first quoted lines) exist for v2-v3 migration. Additionally, they allow the pipeline to use Zend\Expressive\Middleware\RouteMiddleware
instead of Zend\Expressive\Router\PathBasedRoutingMiddleware
which may be harder to remember.
The ApplicationPipeline
entry is because we likely do not want a shared MiddlewarePipeInterface
or MiddlewarePipe
service, but the application pipeline does need to be shared. This is a way to disambiguate.
The two ServerRequest-related items are because these are returning PHP callables. I felt it was better to namespace them for uniqueness, and to give them context.
There are some nonexisting classes in the ConfigProvider. Are they there for a reason?
https://github.com/zendframework/zend-expressive/blob/3c365f1c4aec01b5ce1b55477d5f70f405ed503d/src/ConfigProvider.php#L37-L39
https://github.com/zendframework/zend-expressive/blob/3c365f1c4aec01b5ce1b55477d5f70f405ed503d/src/ConfigProvider.php#L43
https://github.com/zendframework/zend-expressive/blob/3c365f1c4aec01b5ce1b55477d5f70f405ed503d/src/ConfigProvider.php#L55-L56