You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filters use a single name as both the query string parameter and the underlying path to the filtered property. This ties the query string parameter to the underlying model: if the model changes, the parameter changes as well and its consumers must be updated. It also exposes internal details that the consumers might not have to be aware of.
I propose to allow setting different names for the query parameters by supporting passing an array of settings to filter properties configuration, e.g.:
Is that a feature you want to have in Core, @soyuka?
Currently I implemented this by extending from the Api Platform filters and adding an additional property to map the filter parameter name to the property (to keep the AbstractFilter::$properties property untouched). Then I override the constructor and the apply() and getDescription() methods to map the properties to their correspondending parameter name.
But I think this feature should be in Core, because then you can decouple the parameter names from the underlying model (like with DTOs plus Data Transformers).
Filters use a single name as both the query string parameter and the underlying path to the filtered property. This ties the query string parameter to the underlying model: if the model changes, the parameter changes as well and its consumers must be updated. It also exposes internal details that the consumers might not have to be aware of.
I propose to allow setting different names for the query parameters by supporting passing an array of settings to filter properties configuration, e.g.:
before
after
The text was updated successfully, but these errors were encountered: