DataTables 1.10 redesign suggestions

DataTables 1.10 redesign suggestions

EranEran Posts: 26Questions: 0Answers: 0
edited February 2013 in General
Hi,

Working more and more with this plugin. I've came to realize that we need a better Model-VIew solution.
I feel as there is too much coupling between the Model/Data and the DOM View.

What do I mean ?
For me, the model is the actual data in the rows of the table.
I think that each row should be represented by a JS object and should be easily accessed and modified.

For example:
fnFindRow([key]) will return a certain row JS object from the table (not the TR DOM element !)
and on this object we'll be able to use functions like

.setAttribute([attribute_name], [value])
.getAttribute([attribute_name])
.remove()
.clone()
etc.

IMO, this approach is the right direction for enabling the use of js libraries such as Backbone js, Knockout, etc.


Having that said, is there a place where we can find the new API that is planned for DataTables 1.10 ?
Maybe you could share your plans with us so we could view them and make suggestions ?

Replies

  • allanallan Posts: 63,523Questions: 1Answers: 10,473 Site admin
    edited February 2013
    Agreed on all accounts. With 1.10 you will be able to do something like:

    [code]
    table.cell( {selector} ).data( 'my data' ).draw();
    [/code]

    At least that is how it is likely to be done! The other way would be:

    [code]
    var row = table.row( {selector} ).data();
    row.first = "1";
    table.row( {selector} ).invalidate().draw();
    [/code]

    where the invalidate call tells DataTables that the underlying data has changed and should be re-read.

    > Having that said, is there a place where we can find the new API that is planned for DataTables 1.10 ?

    Currently no - they are all in my hand written notes at the moment, but I'm hopeful of getting started on the new API soon, when it will be available in git.

    Allan
  • EranEran Posts: 26Questions: 0Answers: 0
    edited February 2013
    Hi Allan,

    I like the second way better.
    In the third line of code, I think you could do:
    [code]
    row( {selector} ).invalidate().draw();
    [/code]
    if you maintain some kind of binding between a row and it's table.

    Anyway, I'd suggest putting up the new API for community discussion even before uploading any code to git and having the plugin's community invovled in future design of the plugin....
  • allanallan Posts: 63,523Questions: 1Answers: 10,473 Site admin
    I'm not sure I see a different between my example and your own, other than you are using a global row function?

    My example could easily be paired down to be:

    [code]
    var row = table.row( {selector} );
    var rowData = row.data();
    rowData.first = "1";
    row.invalidate().draw();
    [/code]

    where `table` is a reference to the DataTable's API (i.e. the 'instance').

    Allan
  • EranEran Posts: 26Questions: 0Answers: 0
    edited February 2013
    I think we're talking about the same thing....
    Of course, you could always have more than one table per page and this is was the reference is needed and could be part of a row object.
  • allanallan Posts: 63,523Questions: 1Answers: 10,473 Site admin
    Yes, you need a reference to the API instance. I'm planning on having the API being able to operate on multiple tables. For example `table.filter( 'Hello' );` would filter all tables that have a reference in the `table` variable by 'Hello'. That could be a single table (the typical case) or multiple tables.

    Allan
This discussion has been closed.