Range filtering: remote or local?

josemota

Hi everyone, I'm trying to create a plugin that uses the range filtering that Allan provides in the docs. However, I want the plugin to be flexible enough to build parameters in order to be sent to the server, in case `bServerSide` is true.

I'm thinking of having a function that evaluates the variable and then either build the params to be sent or push the filter(s) to `$.fn.dataTableExt.afnFiltering`. How would you do it? Should I be considering some best practice already familiar to you or something?

Thanks for the help. If you need some code samples, let me know.

ysor123

I would process such things serverside, not clientside. the doc give you an example of clientside processing.

Maybe that helps you:

[code]
// serialize() : jquery method that creates a query-string,
// ready to be sent to the server
$('#form-1,#form-2').serialize();
[/code]

To short it without general xhtml structure:
[code]






[/code]

You can put your input where ever you want and if you select multiple forms (if you separate filters bottom and top of the page/content area/whatever it will merge the data. (Be carefull choosing unique names in your form inputs.

add a function to datatables which takes a jquery selector (string) as param. This function can be triggered when for example a button is clicked. this function should use the given selector to get the form data and push it to the filters and then draw the table again. Serverside you should use the given params to filter the data building the required query.

Remote processing is better because you select only data u need and not everything and process then using slower javascript. Its also easier because you can directly make a count database query to get the proper iTotalDisplayRecords

josemota

[quote]ysor123 said: Remote processing is better because you select only data u need and not everything and process then using slower javascript.[/quote] Indeed it is.

I am trying to cover all angles possible, since my company intends on releasing the plugin to the community, hence the question.
--
A question rises then: what API function should I add the parameters into? Usually you use `fnServerData` to prepare anything before requesting the data. Would DTinstance.aoData be the place to insert them?

EDIT: I realize that I would have to insert the variables in a volatile way. What I mean is `fnServerData` is set at the plugin initialization. The parameters I send change from draw to draw. Using the `aoData` probably persists over draws, removing items from the array every time between the draws makes no sense, I believe.

allan

> I am trying to cover all angles possible, since my company intends on releasing the plugin to the community, hence the question

Sounds great!

Basically the approach for dealing with server-side processing needs to be quite different from client-side processing. With client-side processing you can use afnFiltering no problem, but this code doesn't get hit when doing server-side processing (or if it does, then it gets ignored) since there is no filtering done client-side at that point. When that happens you need to use fnServerData as you mention. This can be done something like this to add the extra parameters: http://datatables.net/release-datatables/examples/server_side/custom_vars.html . With this you just need to add the two parameters (max and min presumably) to the data sent to the server so it can act upon it.

Due to the different models of where the data processing is done for client/server-side, I don't think a single plug-in would allow both situations I'm afraid.

Allan

josemota

Thanks for the comment, Allan!

The whole idea of the plugin would be to not make the end user split a functionality across different places on the framework. It reminds me of monkeypatching.

Something like a hook system in `fnServerData` would be awesome, but I don't know what it would implicate. Anyway, until that kind of magic happens, I need to inject `fnServerData` the parameters. Is there any way of getting the plugin object in which I store them?

--I guess I need to start sharing some code.-- Have a look at the code here: https://gist.github.com/0e67fc2f272e770051b7

allan

I guess what you could do is always include both methods, suitable for client-side and server-side processing. The client-side one will have no effect on the server-side, so that's not a problem, and fnServerData won't be called for client-side processing, so that should be just fine as well. It's not perfect, but they are two very different ways of dealing with data.

> Is there any way of getting the plugin object in which I store them?

I don't quite understand I'm afraid?

Allan

fbas

You can attach your plugin instance to a DataTables object for direct access. The FixedColumns plugin does this on line 242
[code]
/* Attach the instance to the DataTables instance so it can be accessed easily */
this.s.dt.oFixedColumns = this; // this.s.dt was set to the fnSettings() oSettings object
[/code]

now the plugin object is available at $('#example').fnSettings().oFixedColumns


or you could write an API function to return those values
[code]
$.fn.dataTableExt.oApi.fnMyPluginParamValues = function () {
// ... fill in this function
}
[/code]

and then call the function on your table params = $('#example').fnMyPluginParamValues()

josemota

@Allan, I was trying to know if with I could keep a variable reference inside my object. The gist I gave in my last comment shows a `@table` variable:

[code]class MultipleFilters
constructor : (oSettings, options) ->
# oSettings.oInstance is not it. I need the return value of the
# $("table").datatable() method.
@table = oSettings.oInstance
@aoStack = []
return @boot oSettings[/code]

that I wanted to be the result of:

[code]oTable = $("table").dataTable();[/code]

I guess I'll have to look into FixedColumns and see how they built the plugin. Thanks for supporting this, fbas & Allan. I'll do some digging and report back.