given a 2-column table, first column must be sortable
listx opened this issue · comments
I have this in my recruiting_partnership_datatable.rb
:
class RecruitingPartnershipDatatable < AjaxDatatablesRails::Base
def sortable_columns
# Declare strings in this format: ModelName.column_name
@sortable_columns ||= [
'PartnershipSchedule.start_hour'
]
end
def searchable_columns
# Declare strings in this format: ModelName.column_name
@searchable_columns ||= [
]
end
private
def data
records.map do |r|
[
# comma separated list of the values for each cell of a table row
# example: r.attribute,
r.partnership.name,
r.start_hour
]
end
end
def get_raw_records
# insert query here
PartnershipSchedule.recruiting
end
# ==== Insert 'presenter'-like methods below if necessary
end
and also in my JS file:
$("#recruiting-partnerships-table").dataTable
processing: true
serverSide: true
pagingType: "full_numbers"
ajax: $("#recruiting-partnerships-table").data("source")
# disable search bar
searching: false
columns: [
{sortable: false, searchable: false}
{sortable: true, searchable: false}
]
This always crashes on initial load. If I then click on the 2nd column header to sort it, it works as expected. I supposed the initial sorting is messing it up.
The title of this issue is drawn from the current workaround, which is to switch the columns
field values like this:
columns: [
{sortable: false, searchable: false}
{sortable: true, searchable: false}
]
. Now it doesn't crash, but now the UI is wrong (click on first column header to sort by the 2nd column values).
@listx please refer to this comment: #77 (comment) (to an issue by you 😄) where I mention that you start by the html view... so, basically if the html view has 2 columns, then your sortable and searchable columns methods should have 2 columns... if you only care about one of them (by specifying its sortable or searchable behavior through JS), then the other can be anything.
Realizing this (now) is (very, very, very) far from ideal... so I'm making a note to rework how columns are defined... but this will be available in another release.
Ah yes, I meant to reference #77 because you did say that ordering was important. I suppose we can close this issue for now and just move the discussion (if any --- this is not my specialty and I defer all judgments to you) to #84. Feel free to close --- I am not sure how you want to keep things organized in the issue tracker.
OK, will close this issue for now.
I think that based on a scenario like the one you describe (which matches some scenarios described in other issues), a better API for handling columns (both sortable and searchable) is the right thing to do.
So, this will be addressed on #84 and targeted to be released on v.0.4.0 ... though as it will be a change in the API, not sure if it should be considered a major version bump (v.1.0.0)...