Add missing Symfony Routing options to operations configuration #1472
Conversation
|
It would be nice to do it for all constructor arguments of the |
|
@dunglas It sounds right. I'll update the PR asap, most probably not tonight but tomorrow. |
|
OK I lied 🤥 |
philippecarle
changed the title
|
This could be a fix on 2.1 wdyt? |
|
Base branch updated on 2.1 |
| [], | ||
| $operation['options'] ?? [], | ||
| $operation['host'] ?? '', | ||
| $operation['schemes'] ?? [], | ||
| [$operation['method']] |
There was a problem hiding this comment.
Can you also add the condition argument?
There was a problem hiding this comment.
Missed it 🙄 , fixed by last commit
|
Just a question (and I've no strong opinion about that): should we add all these new options to the root operation array (it may be confusing, for instance "condition"), or should be put them under a "routing" key? ping @api-platform/core-team |
|
In my user opinion, it would be quite confusing too to have them under a routing key and it would be quite unaesthetic too to have another nested optional key/value pair holding routing options while some are at the top level of the operation (path, method & requirements). Just sayin' 😀 |
|
Ok then LGTM. |
|
Thank you @philippecarle! Would you mind opening a doc PR please? |
|
api-platform/docs#330 is already there @dunglas |
I was trying to associate a default key/value association to a given route following this Symfony documentation when I realized there is actually no way to do this as the
defaultsconfiguration of a Symfony route is not available in operations. This PR tries to fix this.I don't know much about the new subresources feature yet and couldn't really guess if it was relevant to also cover these routes.
Please let me know if this PR sounds fine to you and if I should pay attention to the subresources topic.