server-side: searchpanes with column filter integration?
server-side: searchpanes with column filter integration?
Apologies for the lack of a test case; I tried to set one up but couldn't figure out how to load searchpanes options using the example server-side script on the live site. I'm happy to try again, if someone can point me in the right direction.
I can't for the life of me get column filters to work with viewTotal/casecadePanes when using server-side processing.
I'm using the Editor php libraries to load the searchpanes options. Selecting an option in one of the panes causes the other panes to update their options and display the number of filtered rows, as expected. Works great. When I text in a column filter (or global search), the pane options still reflect the full, unfiltered data set, and the filtered count is not displayed.
I would like for it to behave as in the [example] - is this functionality available in the Editor server-side scripts, or will they need to be modified? I played around a bit with SearchPanesOptions.php. In the exec function, I didn't see the column filters being added as 'where' conditions to the $query that gets the viewTotal counts (under the comment "// Set the query to get the current counts for viewTotal"), so I tried adding this block of code from Editor.php:
(https://datatables.net/extensions/searchpanes/examples/advanced/columnFilter.html "example ")
for ( $i=0, $ien=count($http['columns']) ; $i<$ien ; $i++ ) {
$column = $http['columns'][$i];
$search = $column['search']['value'];
if ( $search !== '' && $column['searchable'] == 'true' ) {
$query->where( $this->_ssp_field( $http, $i ), '%'.$search.'%', 'like' );
}
}
This got me closer: now, after applying a column filter, the ajax response includes the correct filtered counts and totals for each searchpanes option. The panes themselves, however, refuse to display the filtered counts, until I select a searchpanes option. Once I do that, the count is displayed, properly taking into account the column filter, but I would like for those counts to be displayed once the column filter is applied as in the example. Binding searchpanes.rebuildPane() to the draw() doesn't help.
My questions, to summarize:
(1) is [column filter integration] natively available with server-side processing using the Editor library, or are modifications necessary?
(2) if it should work using the unmodified libraries, is there a trick for getting it to work? (I recognize that helping me debug will be a challenge absent a test case; sorry again for that).
(3) if I need to modify the scripts: (a) am I on the right track with the block of code that I copy/pasted from Editor.php? and (b) how do I get the panes to update with the count information in the ajax response without having to first select a searchpanes option?
(https://datatables.net/extensions/searchpanes/examples/advanced/columnFilter.html "column filter integration")
Whether or not I get this to work, just want to say thanks for all you do -- datatables is an unbelievably useful project.
This question has an accepted answers - jump to answer
Answers
SearchPanes should integrate okay with column filtering, as they don't use the same parameters / mechanism in the PHP libraries.
Can you show me your client-side code please? I'm wondering if there is just a missing link in triggering a draw for the column filtering since you note that isn't working.
Allan
Thanks Allan. To make sure my customizations weren't the issue, I just created a new configuration using the Editor generator and made very few modifications beyond adding my db config, adding ->searchPaneOptions( SearchPaneOptions::inst()) for certain columns to the server script, and adding column filter code identical to the basic example. Same behavior: after entering column filter text, searchpanes filtered counts do not display.
Here's my js:
html:
and php:
Really appreciate your looking into this.
Oh sorry - I might have misunderstood a bit. The column filter is actually working, but SearchPanes' counters aren't displaying?
Allan
Sorry for being unclear. Yes, column filters are working properly on their own. The searchpanes always display the total counts, and after selecting a searchpanes option, the filtered counters display in the other panes as expected. But the counters are not interacting with the column filters at all: if no searchpanes option has been selected, the filtered counts do not display after applying a column filter; if a searchpanes option has been selected thereby activating the filtered counters, the counters do not update to reflect column filters. In short, viewTotal only seems to be working when the table is filtered via searchpanes.
In the Column Filter Integration example (https://datatables.net/extensions/searchpanes/examples/advanced/columnFilter.html), if I type "software" into the position column filter, the searchpanes count the visible rows and display the totals. My column filters work fine on their own, but do not seem to interact with the searchpanes in any way.
Thanks so much ... I've been spinning my wheels on this issue for days.
Ah, please note the comment on
searchPanes.viewTotal
:So it would be best to disable that feature, I'm afraid.
Colin
Thank you, Colin! I saw that note in a few places and apparently misinterpreted it. Much appreciation.
I had the same issue as @sk1597 and I spun my wheels for only an hour before coming across the documentation that @colin pointed to.
I would like to request that Server Side Processing update the SearchPanesOptions and counts based on filtering.
My website is a real estate information platform, and people want to filter properties, but it's hard to know which property type to choose from (there are dozens that the tax assessor uses) if they don't know which property types are available in a person's selected geography.
Hi @stevevance ,
SearchPanes should support both
searchPanes.cascadePanes
andsearchPanes.viewTotal
when using a fullyserverSide
processing setup, so this may still be possible but you will have to do it that way rather than loading options purely over ajax.SearchPanes has undergone a complete rewrite since this post was last updated. The code for this is currently in the nightly builds. I've noticed a few issues there this morning though which I have raised in an issue internally (DD-2476 for my reference). I'll report back here when I've got those fixed.
Thanks,
Sandy
Hi @stevevance ,
I've made a daft mistake - was looking at the wrong branch when testing SearchPanes out for SSP. When SearchPanes 2 is released, these will also be released and you should be able to use
searchPanes.cascadePanes
along withserverSide
processing just fine. We hope the release will be within the next few weeks.Thanks,
Sandy
I'll tag up and release SearchPanes 2 tomorrow - keep an eye out for it
Allan
Hi Sandy and allan, I see the new SearchPanes 2 release. I installed it and it cascades correctly, but it cascades on the full table.
My Editor SSP has several
$editor->where
statements to limit results from the full table based on overlapping geography.Can these same WHERE statements be automatically applied to each field's
searchPaneOptions
method?That way I don't have to add the WHERE statements to each of the fields because they could grab it from the
$editor
.I'm not sure if that's possible, but I'll leave it for Sandy to reply - he'll be able to reply towards the end of the week,
Colin
Hi @stevevance ,
We have some concerns over how implementing this may affect the behaviour of other aspects of error, joins being one of them. So it's not a change we will make to the editor libraries at this time.
Instead you could write a function and pass that into where statements on all of the
SearchPaneOptions
. That would mean that changes would only have to be made in once place. Something like the below...You can get more details on how to pass functions into where calls on this page.
Thanks,
Sandy
@sandy What you suggested is exactly what I ended up figuring out myself a few hours before you mentioned it!
The issue is that I have to apply that filter to each and every SearchPaneOptions method, and there're about five for now. Although I should probably write a function to reduce the code.