Add a filter for serialization groups#1111
Conversation
1af71a4 to
9694e58
Compare
| * | ||
| * @author Baptiste Meyer <baptiste@les-tilleuls.coop> | ||
| */ | ||
| class GroupFilter implements FilterInterface |
There was a problem hiding this comment.
I followed the same standards as ORM filters: not final + protected methods/attributes.
There was a problem hiding this comment.
So @dunglas, should we keep consistency with ORM filters or should I follow your requested changes?
There was a problem hiding this comment.
ORM filters support only the array syntax. So, same for this new one.
There was a problem hiding this comment.
No, I talk about final + protected @dunglas 😋
| */ | ||
| class GroupFilter implements FilterInterface | ||
| { | ||
| protected $overrideDefaultGroups; |
| */ | ||
| public function apply(Request $request, bool $normalization, array $attributes, array &$context) | ||
| { | ||
| if (empty($groups = $this->extractGroups($request))) { |
| return; | ||
| } | ||
|
|
||
| if (!$this->overrideDefaultGroups && !empty($context['groups'])) { |
| * | ||
| * @return array | ||
| */ | ||
| protected function extractGroups(Request $request): array |
| $groups = []; | ||
|
|
||
| if (null !== $groupsParameter = $request->query->get($this->parameterName)) { | ||
| if (is_string($groupsParameter)) { |
There was a problem hiding this comment.
Why supporting both syntax? We only support the second one in other filters.
There was a problem hiding this comment.
I don't think we should explode or do any transformation on query parameters. Just let symfony do the work here.
I'd propose:
$groups = $request->query->get($this->parameterName);This method can then be removed as this one line should be enough.
There was a problem hiding this comment.
I followed what you described in your issue: ?groups=foo,bar,baz and I added the array syntax. So... should I implement the issue syntax or array syntax or both?
There was a problem hiding this comment.
After a second though, I was wrong :) We should just support the array syntax, just like for other fields (consistency...).
| $resourceFilters = $resourceMetadata->getItemOperationAttribute($attributes['item_operation_name'], 'filters', [], true); | ||
| } | ||
|
|
||
| if (empty($resourceFilters)) { |
9caf397 to
abe708b
Compare
| return; | ||
| } | ||
|
|
||
| if (!$this->overrideDefaultGroups && isset($context['groups']) && is_array($context['groups'])) { |
There was a problem hiding this comment.
About is_array($context['groups']), I'm not really sure how we should handle the case where $context['groups'] exists and is not an array:
- cast
$context['groups']to array and apply the filter - do not apply the filter when
$overrideDefaultGroupsis true or false (so in all cases) - apply the filter when
$overrideDefaultGroupsis true - apply the filter and overwrite the value of
$context['groups']in all cases (current behavior)
WDYT?
There was a problem hiding this comment.
What is $context['groups'] if not an array? I think we should cast is as one.
There was a problem hiding this comment.
What is $context['groups'] if not an array?
I don't know, it's just an assumption!
There was a problem hiding this comment.
Should be a string, therefore we could cast it as array.
abe708b to
44cdc17
Compare
| * | ||
| * @author Baptiste Meyer <baptiste.meyer@gmail.com> | ||
| */ | ||
| final class SerializerContextBuilderFilter implements SerializerContextBuilderInterface |
There was a problem hiding this comment.
SerializerFilterContextBuilder?
|
To restate what I've raised in #1082 (comment), I think we should not introduce misfeatures like this... |
|
If we are to have a "property group" filter, then the "property groups" MUST be exposed as resources. That's the way to keep things as hypermedia. We need to always keep these principles in mind, as we claim that API Platform is a hypermedia framework / library. 😄 |
teohhanhui
left a comment
There was a problem hiding this comment.
Please take #1111 (comment) into account. Which also means this needs to be generalized into a "property groups" filter, not a "serializer groups" filter (implementation detail).
|
@teohhanhui I'm not sure to get exactly what you have in mind? Can you give us some details? It's also a 100% optin filter. |
|
Regarding the implementation details leak, this is not true. As stated just before, filter is 100% optional and must be enabled manually by the developper. When doing this, you know that the groups will be exposed publicly, and you need to take care of this. It's the developper responsibility. |
61b97bb to
cb4d458
Compare
|
Yeah, I guess it must be very hard to expose the property groups as resources. But I wish we could change "groups" to "property_groups"? |
|
When I said it's a leak of implementation detail, I meant that these groups are not defined anywhere. They are not exposed as resources, they are not in the Swagger doc. So they're magical as far as the client is concerned... Out-of-band information which is a big nono. |
|
I agree about the out of band information. However this is not the case the About the name, I prefer |
b2df66a to
3d71742
Compare
3d71742 to
e3c17c8
Compare
Uh oh!
There was an error while loading. Please reload this page.