Repository navigation
Facilitate usage of filters #8
Description
Activity
I'm not sure it's a good idea to match directly on the request stack in case you want a route-related filter.
Here is an idea of implementation that keep BC. What do you think about adding a
RouteAwareFilterInterfacewith a trait like this:trait RouteAwareTrait { private $route; public function setRoute(string $route) { $this->route = $route; } }
But another idea (potentially better) is to add a new parameter
extra_filtersto the route we define. WDYT?The only one I could see is
- GET /line_items,
line_items - GET /orders/{id}/line_items,
order_line_items
Imagine a that use
{id}to filter related line_items in a collection call.
You want this filter to be applied only on theorder_line_itemsroute.
But actually, it's a specific use case, so I guess you can depend on Request in your filter for this @Nek-- GET /line_items,
The filters are used to filtering a collection of items.
It is common to want a filter applying only for a specific route.
Unfortunately, the method (
supports(string $class)) doesn't have the request. To implement this logic you have to inject therequestStackand do the classic checks against null value.It could be helpful and have sense to inject the current request to the support method (and only support)
This is BC IMHO, but what do you think @Nek- ?
This issue was originally written by @mcsky on biig repository.