DataTables as an input with serverSide
DataTables as an input with serverSide
![Loren Maxwell](https://datatables.net/forums/uploads/userpics/907/nQU402M3AJ88T.jpg)
in DataTables 2
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.
This question has accepted answers - jump to:
Answers
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.
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 withserverSide
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
andorder
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
andorder
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
andorder
stuff to the server ahead of the actualajax
call for the data itself is in thepreHxr
event. This could also be used to modify thestart
value itself for the followingajax
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
?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
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.
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
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.
Thanks @allan -- I'm curious about:
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
!
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. Onget
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
Thanks for the explanation, @allan.
And as always -- thanks for the excellent code and the excellent support!