DataTables as an input with serverSide

Loren Maxwell

Is DataTables as an input fully compatable with init serverSide = true?

I know I can select and submit a value with serverSide, but it doesn't seem like the _jumpToFirst method works as intended, which would be to find the specific page of the current value and jump to that.

Loren Maxwell

Ok, ok, the obvious occurred to me while I was driving into work -- this is an issue that needs to be addressed with the initial set of rows returned by the server itself.

Loren Maxwell

This is not as straightforward as I had originally hoped.

I have not programmed any of this yet and won't have time to do it for a couple of days, but I wanted to get feedback from the group to see if I'm on the right track.

The basic problem has to do with finding the correct start for the initial draw (emphasis only added for clarity, not to be taken as shouting or anything like that! ).

For the DataTables as an input (DTI), the _jumpToStart method finds the current value (again, emphasis only for clarity) from the set of rows in the table and then "jumps" to it, but with serverSide the current value may not be in the set of rows the DTI has access to,

So the correct start (after factoring in the length, search and order stuff) would be whatever would return the set of rows containing the current value and then the DTI would be able to find the current value to jump to.

I believe to find the correct start, a separate ajax call needs to be made to pass the current value to the server, along with the length, search and order stuff, so the database can calculate where the current value would fall in the order and then from there calculate the correct start.

Without modifying the DTI code itself, the only opportunity I see to pass the current value and length, search and order stuff to the server ahead of the actual ajax call for the data itself is in the preHxr event. This could also be used to modify the start value itself for the following ajax call to get the data.

Am I on the right track?

And if so, would there be any chance this might be incorporated into the future version of DTI so that it wouldn't have to programmed for each DTI that uses serverSide?

rf1234

I might be completely misguided but I don't understand why you would use "serverSide" for field type "datatable". I mean you can use it for the primary data table, but does it make sense to use it for the child table? The child table is usually not that big that "serverSide" should be required?!

Can you clarify and maybe point to one of the examples that best describes your use case.
https://editor.datatables.net/examples/datatables/index.html

Loren Maxwell

Thanks, @rf1234 -- I agree that for the most part serverSide would not be needed.

However I have a couple of cases where serverSide would be helpful.

My website tracks approximately 2500 high school football teams. For the games themselves I need to input each opponent so I could have two datatable inputs that have that many records each.

Additionally, there are several hundred cities in the database the games could be played in.

All three of those datatables would be on the form at the same time.

Finally, there are about 5,000 coaches in the database, so assigning coaches to teams using serverSide on the datatables input would be helpful as well.

Those are just my cases that I have offhand, but I think a serverSide option for a datatable input would be useful anywhere where there are large datasets with one-to-many relationships.

allan

Is DataTables as an input fully compatable with init serverSide = true?

No. It is not something I would suggest doing. The primary reason for that is that the "value" of the datatable field is stored as the selected rows. With server-side processing we only have the rows that are shown. Therefore if the field's selected value is on a different page, it will be lost.

Until Select has server-side support (which will almost certainly involve a major amount of work in the server-side script), I would urge server-side processing not to be used on a datatable field.

In fact, I'll add a warning to the docs and might put a block in the code.

Allan

rf1234

My website tracks approximately 2500 high school football teams. For the games themselves I need to input each opponent so I could have two datatable inputs that have that many records each.

Additionally, there are several hundred cities in the database the games could be played in.

All three of those datatables would be on the form at the same time.

Finally, there are about 5,000 coaches in the database, so assigning coaches to teams using serverSide on the datatables input would be helpful as well.

It is a lot, Loren! But I think not enough to require "serverSide". I only use it for tables that are a lot larger - mainly because "serverSide" has so many downsides when it comes to searching for rendered values etc. Hence I try to avoid it wherever possible.

Loren Maxwell

Thanks @allan -- I'm curious about:

if the field's selected value is on a different page, it will be lost.

I might be understanding it wrong, but in the case of a datatable input isn't the value stored in the field instance itself and the datatable portion essentially just a way to display it (along with providing a mechanism to edit the value through selecting/deselecting)?

If I change the field type to a regular input the value is still there, although the display of it is different (as well as the mechanism to edit it through typing).

If that's the case then it would seem a datatable input might actually be the time serverSide could be fully compatible with Select since the field instance tracks the values.

Maybe I'm thinking of it incorrectly or maybe there are other impacts to the datatable input code that would have to be tackled to make this possible.

@rf1234 -- ok, ok, you've convinced me!

Mine might not be a use case that would warrant serverSide or warrant the changes that would be required to make serverSide possible -- but I'd still love to see it possible for the day my website grows to a gazillion schools and coaches !

allan

I might be understanding it wrong, but in the case of a datatable input isn't the value stored in the field instance itself

No. What happens is that on set of a value the DataTable becomes the single source of truth of the end user's selection of the values. On get the values of the selected rows are read back.

It would be possible to change it so that an item is removed from a list of values on deselect - that might solve this issue. I'd be worried about what happens if you delete an item from the list of options though, then it might never be deselectable (although the database integrity should really have cleaned that up).

I will consider that for a change.

Allan

Loren Maxwell

Thanks for the explanation, @allan.

And as always -- thanks for the excellent code and the excellent support!