DT_RowId on 4.0

[Svashta]

Hi,

I am struggling with migration to new version. I was not able to use array of data like i had in previous version, so i am now migrating to hash of data. Now, DT_RowId value is not on TR anymore and the table doesn't show because i have much more logic bound to this ID. If i do datatable debug, i can see column definition for DT_RowId with proper values.

So, only TR is not updated anymore...is this normal in 4.0 or am i missing something.

Also, i have to admit, defining client side columns as a BIG drawback from version 3. I don't understand why the need of 2 definitions of columns - it is redundant and very confusing.

[Svashta]

Ah yeah. My bad. I have a function that makes TR ID based on DT_RowID and as i have switched from array to hash, i have to change the function too...

Sorry

[ajahongir]

I was not able to use array of data like i had in previous version, so i am now migrating to hash of data.

well, if you are meaning

  def data
    records.map do |city|
      {
        id: city.id,
        name: city.name,
        iata: city.iata,
        country_name: city.country.try(:name),
        custom_column: city[:custom_column]
      }
    end
  end

and

  def data
    records.map do |city|
      [
        city.id,
        city.name,
        city.iata,
        city.country.try(:name),
        city[:custom_column]
      ]
    end
  end

you can use both, its on your own.

if you are meaning defining columns on server side - yes its, now we define them as a hash

  def view_columns
    @view_columns ||= {
      id: { source: "City.id", cond: :eq },
      name: { source: "City.name" },
      custom_column: { source: "custom_column", cond: filter_custom_column_condition },
      iata: { source: "City.iata" },
      country_name: { source: "City.country_id", cond: filter_country_condition },
    }
  end

I don't understand why the need of 2 definitions of columns - it is redundant and very confusing.

well, we need to make sure that client side columns are connecting so our server side columns.

so on front stage we gave a name for each column like a here and on server side we also gave a name for every column on out db table like a here

so now, our tables(client side and server side) are connected with right names and you can enjoy with sorting and searching on out of box. if you have some complex solumn or seraching on database table you have to define custom methods like here

sure 0.3x version was an easier to define but it does not suppoted sorting and order by default!

[Svashta]

My problem is with dynamic columns. I have some table data (column) which should be visible only when some conditions are met. I have been able to deal with this dynamics with this gem and not struggle with it in datatables js definition/config.

I am not sure yet how it will behave now, but i think i will have problems....

[ajahongir]

I dont see any problems with dynamic columns.

1. you can define your all columns on server side, and client side it should be okay
2. then you have just by permission send data which you want(it may be not all fields). also you have to hide those columns on client side to.

remembers client side and server side columns connects by name! not be order number or anything else..

[ajahongir]

you could have problems with 0.3 version because it connects columns my column definging order. if you hide or remove some solumn or change an order your code will broken. because you connect them by order.

[ajahongir]

you have to just run this example project any see how it works - https://github.com/ajahongir/ajax-datatables-rails-v-0-4-0-how-to

[Svashta]

Aha! I think this might then actually be beneficial. I had exactly the problem you mentioned - columns binded by order, not name.

So, now it should be actually easier :) Ok, I've managed to display the datatable now - i need to test it thoroughly...

Thanks for the info!

[ajahongir]

So, now it should be actually easier :)

exactly, now its more flexable

I had exactly the problem you mentioned - columns binded by order, not name.

thats why we pass data to client side as hash and gave a name on client side

so these 2 connection we need to connect server side data with client side

BUT we have another connection this is not required connection. its need if you want sorting and searching on client side!

so if you want sorting or searching on ID column you have to connect only one column. and should not connect others. like this

  def view_columns
    @view_columns ||= {
      id: { source: "City.id", cond: :eq }
    }
  end

if you dont need sorting&ordering just leave an empty:

  def view_columns
    @view_columns ||= {}
  end