[#34288] - [4.0] Centralized, maintainable handling of web service filtering
- Pending
- Medium
- Build: 4.0-dev
- # 34288
- Diff
- pjdevries:web_service_filtering_revisited
User tests: Successful: Unsuccessful:
Pull Request for Issue #34100
Summary of Changes
Centralize filtering of data sets for relevant web service components. In this PR those are:
- com_banners
- com_categories
- com_contacts
- com_content
- com_fields
- com_tags
- com_users
Filters must be passed in accordance with the JSON:APIhttps://jsonapi.org/format/#fetching-filtering) specifications. Mapping of filter request parameters is done by means of an array, providing mappings between query parameter names and model state names. The mapping also contains information about the data type for proper input filtering. A map element looks like this:
'query param name' => [
'name' => 'filter.model_supported_filter_attribute_name',
'type' => 'input_filer_type'
]
The actual mapping is done in a utility method of Joomla\CMS\MVC\Controller\ApiController which is called from its displayList() method.
Testing Instructions
Call any known list endpoint with one or more applicable filter parameters. For example:
{{base_path}}/api/index.php/v1/content/article?filter[category_id]=10
{{base_path}}/api/index.php/v1/content/categories?filter[search]=Uncategorised
etc.
Documentation Changes Required
As far as I know, no documentation for filtering exists yet.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
| Labels |
Added:
?
?
|
||
This looks pretty sensible to me and I like it :)
Thanx for the positive feedback. Honorable mention goes to @joomdonation for suggesting the concept to start with.
1. I think there should be a setting that allows you to override the state name - so you can have a filter that corresponds to a different state name if desired.
Not sure I understand. State names are hard coded in the models. Why would anyone want to map a filter to a different state name than what the filter is intended for? Isn't it up to the server to define the api and for the client to simply consume it the way it is defined? Or am I misunderstanding what you mean?
2. I know I said I wasn't wedded to the e.g. category_id thing - but i think it should be consistent. If we are updating the filter we should update the view to match it.
I definitely agree the api should be consistent. The views completely escaped my attention.
There are two parts to this consistency:
- Consistent attribute names in requests and responses per component.
- Consistent attribute names across all components.
What do you propose?
1 small step at a time
Not sure I understand. State names are hard coded in the models. Why would anyone want to map a filter to a different state name than what the filter is intended for? Isn't it up to the server to define the api and for the client to simply consume it the way it is defined? Or am I misunderstanding what you mean?
No I totally misread the code. I didn't realise the key in the array was the key in the api request
Consistent attribute names in requests and responses per component.
For now just in the components where there is already filtering change the models (and possibly their relations code) to point to your new expected property names.
Consistent attribute names across all components.
Aside from conventions it's pretty hard to normalise things across components. I mean I guess you can build some of it out of traits but I think it's probably going to cause more trouble than just having clear conventions.
| Labels |
Added:
?
Removed: ? |
||
| Labels |
Added:
?
?
Removed: ? ? |
||
This looks pretty sensible to me and I like it :)
Two things: