allow developer to specify iri for operations#2213
Conversation
| * @throws RuntimeException | ||
| */ | ||
| public function getIriFromItem($item, int $referenceType = UrlGeneratorInterface::ABS_PATH): string; | ||
| public function getIriFromItem($item, int $referenceType = UrlGeneratorInterface::ABS_PATH, $context = []): string; |
There was a problem hiding this comment.
We can't change this interface it breaks the backward compatibility :/.
There was a problem hiding this comment.
hi, there is a default value, it should not break the compatibility, can you explain it further ?
There was a problem hiding this comment.
Sure, we respect the symfony backward compatibility promise and we can't add arguments:
https://symfony.com/doc/current/contributing/code/bc.html#changing-interfaces (see the Add argument with a default value => No).
Don't worry about this yet, I'm sure there's a solution that doesn't involve adding context here!
There was a problem hiding this comment.
A solution is to add a new interface extending the existing one. See https://github.com/api-platform/core/blob/master/src/DataProvider/ContextAwareCollectionDataProviderInterface.php#L32 for instance.
soyuka
left a comment
There was a problem hiding this comment.
I can definitely see an interest in this 👍. We may not need an expression evaluator though, I think that a simple properties array would be enough and would maintain consistency with our filters for example.
get:
path: '/admin/orders'
force_eager: false
access_control: is_granted('app_order_view')
iri:
route: 'api_orders_get_item'
properties: ['id'] # will take $order->getId() through the PropertyAccessor | <argument type="collection"/> | ||
| <call method="setContextVariable"> | ||
| <argument>container</argument> | ||
| <argument type="service" id="service_container"/> |
There was a problem hiding this comment.
can we avoid using a setter and especially injecting the service container?
There was a problem hiding this comment.
you are right , the PropertyAccessor is enough for current case
| <argument type="service" id="api_platform.identifier.converter" on-invalid="ignore" /> | ||
| <call method="setExpressionEvaluator"> | ||
| <argument type="service" id="api_platform.expression.evaluator" /> | ||
| </call> |
There was a problem hiding this comment.
same, we should prefer direct injection, but there's an issue with BC break again.
|
when serialize object has object properties like an Order object has a property payment who is also an object. this PR won't work, because the resolved IRI for order is also passed into payment. the IRI is indeed a problem, see Please let us to decide if an entity it is dereferencable or not, don't fore us to do this, it only work when object has no properties that are managed by api-platform . |
|
It looks like this PR has been mangled with your fork. Can you restore only the appropriate changes to ease the review @videni? For the record, I'm 👍 to allow "internal" IRI (urn for instance). |
now we can specify IRI for individual operation, this PR resolves issue 839 I created, we should let the developer decide what IRI is used for resource.