Column.getCells() returns only the VISIBLE (paged) entries

The code below is reformat Dates for all Columns which Title contains ‘date’… but only for the VISIBLE entries (pressing the [Next] page button shows old-format Dates).

Wheter or not this is the intended behavior, you can force Column.getCells(true) to return ALL the column entries to avoid breaking existing code (and extend the function’s reach).

 var xxxtable = new Tabulator("#ex-table",{
 height:"100%",
 virtualDom:true,
 autoColumns:true,
 resizableColumns:true,
 layout:"fitDataFill",
 tooltips:true, tooltipsHeader:true,
 selectable:true,
 pagination:"local", // load all data, then generate paged view
 paginationSize:14,
 paginationButtonCount:1,
 persistenceID:"tablex",
 persistenceMode:"cookie",
 persistentLayout:true,
 });

 // ---------------------------------------------------------------------------- 
 // change D/M/YYYY dates to DD/MM/YYYY dates in all columns containing 'date'
 // ---------------------------------------------------------------------------- 
 { var cols = xxxtable.getColumns();
   for(var i = 0; i < cols.length; i++)
   { var colName = cols[i].getField();
     if(colName.indexOf("date") >= 0)
     {  var dateColumn = xxxtable.getColumn(colName);
        for(var cell of dateColumn.getCells()) 
        { var value = cell.getValue();
          if(value && value.length < 10)
          { value = value.split("/");
            cell.setValue(padDate(value[0], 2) + "/" 
                + padDate(value[1], 2) + "/" + value[2]);
          }
        }
     }
   }
 } 

Any other way to resolve this issue in the meantime is more than welcome! =)

[olifolkerd]

@G-WAN

In this case this is because you should be using a Formatter if you want to change the output of the columns in the table, these are run as the data is displayed, there is no need to iterate through the table data separately.

if you need to update the data itself, you should be using a Mutator.

The whole point of the virtual DOM is that it reduces the overhead on the system during the initial load by only generating elements of the table as they are needed, which means that until a row is first scrolled into view (or loaded on a page) it is not available for manipulation.

I understand there is a bit of overhead to learning how a new library works, but please do not overlay your expectations on how the table works to what others think. Tabulator has been around for years and its operation has been heavily guided by feedback from the userbase. The chances are if something isnt working the way you think it should, it is because there is a different feature of the table you should be using instead.

If you have a specific application you need to work towards then please consider posting a request asking “how do i” and experienced users can point you in the right direction. using a new library means adapting to the paradigm in which it is written so please approach it from that point of view.

and with reguard to your last comment, the code not mis-used at all, the thead and tbody tags are specifically designed for delineating the header and footer of the table. which is exactly what Tabulator requires to determine the header and footer of the table. please see documentation here If you do not format your data to fit the input expectation of Tabulator, that are clearly outlined in the documentation then it is no surprise that it misinterprets your table.

Cheers

Oli 😃

[G-WAN]

Thanks, but the real issue is how a language is used - or misused, and our few exchanges have demonstrated on which side Tabulator stands… going as far as to DELETE the posts where the project leader was wrong (and edit my prose elsewhere):