Custom (browser) rendered columns on serverside Searchpanes implementation
Custom (browser) rendered columns on serverside Searchpanes implementation
Hi everyone,
I have a rather large datatable (& editor) in terms of both columns and dataset. It has been growing increasingly slow as the rows go up.
I use the searchpanes for filtering the columns, some of which are directly from the database, whilst others are custom rendered on the browser. (ex. concatenation or maths)
I tried converting to serverside processing (big improvement) however the searchpane function for my custom rendered columns is lost (no data).
Does anyone have an idea on how to overcome this?
Thanks a lot
Answers
See if this blog helps.
Kevin
If you change your settings to serverside you have to accept that the search function is performed on the server based on the raw data BEFORE getFormatting. That is very different from what you are used to!
To make search work again you can either manipulate the data entered by the user to match the format on the server or build views that emulate end user rendering on the server. These views could then be searched by Editor.
Either way: It is a lot of work. I posted a couple of things on that some time ago in this forum.
This is on manipulating the search data client side:
https://datatables.net/forums/discussion/comment/125435/#Comment_125435
This is a use case to search money market rates from a server side data table. Two languages are supported, English and German. The number and the date formats deviate from each other in English and German - and mostly they also deviate from what is saved in the data base.
This is the Editor instance server side (PHP):
These are the definitions of the two views I use for the search: rate_search_german and rate_search_english
And finally the client side data table:
I turned off search in the individual columns in columnDefs as well.
As you can see: this is highly individual. I would only use it if there is no other way ... You might as well have to limit user search.
Thanks everyone for the suggestions!
@rf1234, I agree that views are a labour intensive but straightforward solution. Nice code!
Best regards,
N