Procent od jakiś dwóch lat pisze jakie fajny jest plugin do jQuery o nazwie DataTables. 3 dni temu w końcu miałem okazję się przekonać, jaki on naprawdę jest fajny! :)
Jeżeli jeszcze z niego nie korzystaliście, to zachęcam do zapoznania się z nim. Na stronie dostępne jest wiele przykładów pokazujących co i jak – naprawdę aż dziw bierze, że coś open-source może mieć taką dokumentację.
Tak czy siak, podczas pracy z DataTables, zacząłem korzystać z dwóch klas, które uważam, że mogą się przydać wszystkim. Pierwsza klasa to parametry jakie DataTables przekazuje podczas ładowania danych/stronicowania/sortowania czy filtrowania:
public class DataTablesParamModel
{
public string sColumns { get; set; }
public string sEcho { get; set; }
public string sSearch { get; set; }
// long not int as nh returns count as long
// it's easier to work like that
public long iDisplayLength { get; set; }
public long iDisplayStart { get; set; }
public int iColumns { get; set; }
public int iSortingCols { get; set; }
}
Niestety, dodanie już kolejnych własności do modelu, wymaga własnego model binder – z tego co się orientuje przynajmniej. Chodzi o to, że część parametrów ma nazwę iSortCol_10 gdzie 10 to numer kolumny w tabeli.
Druga klasa, to wynik jaki oczekuje rozszerzenie:
public class DataTablesResultModel
{
public string sEcho { get; set; }
// long not int as nh returns count as long
public long iTotalRecords { get; set; }
public long iTotalDisplayRecords { get; set; }
public IEnumerable<string[]> aaData { get; set; }
}
Mała uwaga, iTotalRecords powinien zawierać liczbę wszystkich rekordów w bazie danych – nie zależnie od filtrowania, zaś iTotalDisplayRecords, liczbę rekordów po filtrowaniu, ale nie liczbę rekordów zwracanych w danym zapytaniu. Więcej informacji na temat parametrów, wraz z ich opisem, można znaleźć tutaj – także tych brakujących w DataTablesParamModel.
Mając te dwie klasy, zrobienie stronicowania i dynamicznego ładowania danych nie mogłoby być prostsze. Tworzymy naszą akcję w kontrolerze na http post, w której robimy operację stronicowania, filtrowania itp. i następnie zwracamy nasz wynik:
[HttpPost]
public virtual ActionResult PagedIndex(DataTablesParamModel model)
{
// do paging/sorting/filtering etc.
var result = new DataTablesResultModel
{
sEcho = model.sEcho,
iTotalRecords = list.Count,
iTotalDisplayRecords = list.Count,
aaData = list.Select(x => new[]
{
x.One,
x.Two
})
};
return Json(result);
}
Zaś po stronie klienta piszemy następujący kod JS:
$(document).ready(function () {
$('#table').dataTable({
bProcessing: true,
bServerSide: true,
sAjaxSource: '/Home/PagedIndex',
fnServerData: function (sSource, aoData, fnCallback) {
$.ajax({
dataType: 'json',
type: "POST",
url: sSource,
data: aoData,
success: fnCallback
});
},
iDisplayLength: 10,
aaSorting: [[0, 'desc']],
aoColumns: [
{ sName: 'One' },
{ sName: 'Two' }
]
});
});
Proste i zarazem super funkcjonalne! Polecam :)















Zalecam jednak korzystanie z GET, tak jak datatables robi to domyślnie. Nie dalej jak dwa tygodnie temu spędziłem ponad 5 godzin nad problemem, gdzie IE i Opera ucinały w połowie JSON będący odpowiedzią z serwera i krzyczały, że nie można go sparsować. Miało to miejsce tylko wtedy, gdy nie był podłączony żaden debugger/fiddler itd… i dodatkowo pojawiało się może w 20-30% przypadków. Przez większość czasu wszystko działało, a czasami zonk. GET rozwiązało sprawę.
Ciekawe, wygląda nieźle, bardzo podobne do jqGrid’a: http://www.trirand.com/blog/
Comments are closed.