Ajax Loaded SearchPanes Options and array values
Ajax Loaded SearchPanes Options and array values
When loading searchPanes options from (non-serverSide) ajax, a strange behavior happens to array values:
Only exact-match filtering work (eg: select "London"
shows records where city = ["London"]
but omit these where city = ["London", "Paris"]
unlike the default value-included
behavior.
I had a case where I had hundreds of values (default / auto-generated) in my city
search pane but I wanted to only keep the top-10% (those matching more than 10 rows) but no options would allow me to tweak this (other than doing ajax search panes options).
[What forced me to switch all other search panes options to use ajax too, which was not desired, by the way]
But since I started generating the list of options server-side, I tried any possible combination to get back the classic value-include
without success:
Different options formats:
"searchPanes": {
"options": {
"city": [
{
"label": "London",
"total": 6, // Present overall, 6 times (alone or not)
"value": [ // array
"London"
],
"count": 6
},
{
"label": "Paris",
"total": 5,
"value": [
"Paris"
],
"count": 5
}
]
}
or:
{
"label": "London",
"total": 6,
"value": "London", // string
"count": 6
},
{
"label": "Paris",
"total": 5,
"value": "Paris";
"count": 5
"
and a variety of render { filter/display }
and/or orthogonal = "sp", orthogonal { display/filter }
combinations...
... but I couldn't make it.
Questions:
1. How am I expected to provide options
from ajax in the case of arrays, what should the values look like?
2. How to maintain the value-included
behavior for array values when options are retrieved from ajax?
3. Could you consider providing post-processing control over the default searchPane computed options (after computation takes place) so that some options could be removed?
4. Could you consider providing a per-searchPane filtering callback (instead of per-option) so that one can provide computed options from ajax but have control over the filtering logic from javascript? (Currently filter
is only defining the data use by the filtering logic, but not the filtering logic itself which is bound to column.searchPanes.options[].value
5. [bonus] Could you consider making the ajax's searchPanes options override more granular (so that it only overrides SP settings for the columns it ajax SP.options defines but still use DataTable column.searchPanes
options for the others)?
DataTable is an absolute great project. I've chosen it for being open-source but it's not only super powerful but it's all-in-one nature makes development very easy. It's very well documented, forums posts are of great help and the documentation/forum search engine works very well ! It took me a lot of effort and feature-development to push it to its (apparent) limits and end up to posting here
Answers
Dears,
I'm sorry I couldn't overcome these issues and hope a ping after 2 weeks won't hurt too much
Friendly reminder (+ cross-post reference at https://github.com/DataTables/SearchPanes/issues/27)
Hi,
Sorry for the delay in replying - I missed this before! Are you able to give me a link to a page showing the issue you are having. I think I'm going to need to build a local test case to full figure this one out (I suspect you might have hit a case we haven't tested for yet).
This could probably be done with a search plug-in, but yes, perhaps a callback that allows options to be removed could be an option. I'm worried about SearchPanes' being too extendable - it is already dog slow in places, and adding extra code weight and options won't help (I know this single option won't slow things down much, but this is the first request I've seen for such an option, and I'm concerned its utility would be limited).
Is that not possible with the custom pane options? Perhaps you could illustrate further for me?
Yes, I can look into that. Good idea.
Allan