api: offer activities collection under subresource /camps/{:id}/activ…#7141
api: offer activities collection under subresource /camps/{:id}/activ…#7141BacLuc merged 1 commit intoecamp:develfrom
Conversation
|
The tests failed because i did not yet do: Will rebase this branch as soon as #7142 is merged. |
|
Offering this as subresource is fine if api platform support is better by now. But why is this a blocker for caching the endpoint? |
They are currently queried with get parameters, and we don't support that right now when caching. (maybe not related, but: and in the far future, we might even share the cache for one camp, which is easier when we can share the cache for all people who have the access to the camp /camps/1a2b3c4d can access the cache, and we don't have check all camp= get parameters etc) |
I see, I didn't know / remember this. Seems like a pretty big limitation to the caching system, no? There will always be cases where query parameter filtering will be required, e.g. when filtering by multiple attributes, or filtering by a nested attribute of a related entity. Is it not possible to support caching for this? |
7a2592c to
d1471a6
Compare
d1471a6 to
8dce41a
Compare
…ities That we can cache the endpoint.
8dce41a to
8e5aab9
Compare
| new GetCollection( | ||
| normalizationContext: [ | ||
| 'groups' => [ | ||
| 'read', | ||
| 'Activity:ActivityProgressLabel', | ||
| 'Activity:ActivityResponsibles', | ||
| 'Activity:ScheduleEntries', | ||
| ], | ||
| ], | ||
| normalizationContext: self::COLLECTION_NORMALIZATION_CONTEXT, | ||
| security: 'is_authenticated()' |
There was a problem hiding this comment.
Are you planning to remove this in a next step?
There was a problem hiding this comment.
As soon we know we dont use the Ressource anymore
…ities
That we can cache the endpoint.