Open aubiyko opened 4 years ago
You can add the f
to the dom
property and make use of the built in search instead of using external search. But the question is against which column you will search the user input? That's why I have removed f
from dom
in my demo as this package is focused on individual column based search based on datatype.
You can do something similar like what I have suggested in #29 but in a different way as shown below,
if (!string.IsNullOrWhiteSpace(param.Search.Value))
{
var dtColumn = new DTColumn
{
Name = "co", // search operator
Data = "Name", // column name
Search = new DTSearch
{
Value = param.Search.Value // built-in search value
},
Orderable = true,
Searchable = true
};
param.Columns[1] = dtColumn;
}
Note that here I'm explicitly making the search against Name
column with the input entered by user from built-in
search textbox. You can make use of this param.Search.Value
to make search against any column of your wish by following above approach.
Unlike JavaScript this cannot be done automatically as different columns have different datatypes and casting will fail in C#. Lets say you can search the same text against int
or DateTime
field as it will throw exception. Hence this option is not implemented in the package.
Hope this helps.
Give a star if you like this library.
KR, Abdul Rahman
Unlike JavaScript this cannot be done automatically as different columns have different datatypes and casting will fail in C#.
Server-side library could mimic the behaviour of client-side, that is threat everything as string and perform word-bound search with partial matching.
This does a database level search and the SQL formed on the fly for all columns of different type cannot be casted to string. Even if we do so it will sometimes end with doing the evaluation on the code level than in the database level which will have huge performance impact.
SQL formed on the fly for all columns of different type cannot be casted to string.
I've conducted some tests and can't confirn this behavior. Signed and usigned byte, signed and unsigned int, signed long, signed and unsigned short, single and double and even datetime works via simple ToString().Contains(needle)
. String ToString().Contains()
doesn't work, but just Contaings()
do.
Even if we do so it will sometimes end with doing the evaluation on the code level than in the database level which will have huge performance impact.
By EF.Core defaults, client-side evaluation requires additional actions.
Even if casting is possible why to do unnecessary casting to string for all data types?
I actually thank you for the suggestion, i think that is a great ideal, i will look at adding it to the roadmap.
If you would like to contribute this as a Pull Request, i would be happy to accept it.
Built-in DataTables search does send correct JSON to server with non-empty
search
property, but it seems the library simply ignores it. Since search itself is provided, I see this as missed opportunity rather than bug.Your example provides external search facilities instead, but that requires developer interference in JS search handler or server-side controller/API endpoint. Having that done by library itself will be appreciated.
To reproduce:
f
option somewhere into 'dom';