http-middlewares CommandHandler can not retrieve configure RouteOptions via ServerRequestInterface::getAttribute() #162
Comments
BreiteSeite
changed the title
|
@basz wanna have a look into this? |
|
Should work. Might be a bug in zendframework/zend-expressive-fastroute. You could start by checking the getOptions method in that repo. It should indeed use 'values'. Not using fast router myself, nor does the proophessor-do app. |
|
This is a bug in the fast router. I've created an issue there. Switch to aura router if this is blocking you |
|
Seems to be not a bug but a limitation of fastroute (see zendframework/zend-expressive-fastroute#58 (comment)) and the reason prooph choose aura router... |
|
@codeliner - thoughts on this? |
|
yes, it is a limitation on fastroute. That's the reason why we use aura router in the example app. If the router does not provide this functionality you have to pipe a middleware in front of the request handler to map the request to a command. We cannot do much about it. @BreiteSeite your approach is valid. Not sure if we should provide additional middleware. We're not designing a middleware dispatcher and proophessor-do is an example app using expressive together with aura router. We just provide the last handler in the middleware pipe that takes the request body and the command name from a request attribute, creates the command and dispatches it on the bus. The http-middleware package also provides a more generic MessageMiddleware that expects the request body to contain a serialized message. You can use that one if you want to include the command name in the request body: {
"message_name": "My.Command",
"payload": {
"key": "value",
...
}
} |
|
ah ok should have read the comment in the linked issue first ... thx to @xtreamwayz $routeResult = $request->getAttribute(\Zend\Expressive\Router\RouteResult::class, false);
$matchedRoute = $routeResult->getMatchedRoute();
$matchedRoute->getOptions()['values']['prooph_command_name']; |
|
@BreiteSeite want to provide a PR here: https://github.com/prooph/http-middleware ? |
|
arrgh no, next problem ... The snippet above would couple our middleware to expressive router. We cannot do that, sorry. So my first statement is valid again! |
|
@codeliner yes thats why i described my patch as "hack", as i also think this coupling is unnecessary. However it seems evident that there is a lack of some interop-standard regarding the communication between the middleware and the router config. This is why i used another middleware, because communicating from middleware to middleware via request attributes is much more robust. And thats why i think switching the proophessor-do to the middleware approach would be good and also to provide a little helper (not a must-have though) would be the best way to approach this. If you disagree with that, we should at least document this limitation from the example project somewhere (if it isn't already). Maybe i can provide you with the PRs if you tell me what exactly you think should happen here. Another option would be to check for the Zend-Expressive RouteResult as a fallback, however, i'm not a fan. But i think any implementation - including the current one - relying on the router implementation to silently do something unspecified is not the way to go, hence my another-middleware-approach. Let me know what you think we should do here. |
|
@BreiteSeite you could provide a PR for proophessor-do that uses a middleware instead of the aura router to set the command name as an attribute on the request. Maybe that's a good starting point for further discussions. |
|
I had the same issues with FastRoute not picking up the values array a while back. Can't remember how I found the solution, but I've simply replaced "values" with "defaults" and the route works just fine with FastRoute. Haven't tried it with Aura.Router tho. |
|
No activity, closing. |
Here's how i configured the route (slightly anonymized) in zend expressive (inspired by the proophessor-do routing) which does not work:
I'm new to expressive and not 100% sure how route options and request-attributes are meant to be used correctly, but according to the psr interface itself it's the following-definition:
I made it temporary working by applying this hack:
So i think there is no way to pass information 1:1 from the route definition to the Middleware.
It seems we have to use a middleware to pass the information along which command handler should be used. At least if we want to stay framework agnostic.
Maybe prooph can provide a generic one to be used in the future or we have a different way to pass this information along?
Thats how i configured it in the to get it working without the hack:
This issue is mainly to validate if my approach is correct and also can be used to update the proophessor-do example if that's the case.
Also we might create other issues from here for different prooph components (for example to provide a helper callback to pass this information along).
Output of
composer infoThe text was updated successfully, but these errors were encountered: