Я использую подключаемый модуль datatables для обработки наших таблиц. У нас есть этот вариант использования, когда нам нужно получить данные (с разбивкой на страницы) через вызов ajax с использованием bServerSide и sAjaxSource, но мы хотели бы просто отсортировать данные на этой странице, а не получать отсортированные данные с сервера, как в нашем случае это чтение было бы очень дорого.
Возможно ли это сделать? Если да, то подскажите, как поступить. Заранее спасибо!!
Я читал это обсуждение, которое может вам помочь: в основном вы должны инициализировать таблицу с этими параметрами;
"bServerSide" : false,
"sAjaxSource" : "path to your ajax source"
Таким образом, данные загружаются только один раз, и вся фильтрация выполняется клиентом.
Если вы хотите загрузить больше данных, вы можете использовать fnReloadAjax. Вы можете прочитать это обсуждение темы. необходимость.
РЕДАКТИРОВАТЬ. С помощью конвейера вы можете избежать частых вызовов на сервер только для разбиения на страницы (если вы фильтруете данные, вызов выполняется на сервер). Если вы хотите получить данные на сервер только один раз, а затем отфильтровать данные на стороне клиента, вы должны отключить обработку на стороне сервера (белый набор параметров выше). Если вы отключите обработку на стороне сервера, вы можете предоставить пользователю способ получить дополнительные данные с сервера с помощью «fnReloadAjax» (например, кнопку).
Чего я до сих пор не понимаю, вам нужно получить какие-то другие данные с сервера или все, что пользователь получает первым, в порядке?
РЕДАКТИРОВАТЬ 2 - если вы не хотите вызывать сервер, вы можете вообще не использовать AJAX, улучшив существующую таблицу. Просто создайте сторону html-серверов следующим образом:
<table width="770" border="0" id='rdr_home' class='tablesorter'>
<thead>
<tr>
<th>col1</th>
<th>col2</th>
<th>col3</th>
</tr>
</thead>
<tbody>
<?php
foreach ($rows as $row){
//echo all rows here (be careful as for each row you must
//have as many <td> as the column: no colspan!
}
?>
</tbody>
</table>
А затем создайте свой datatable, например, как это
oTable = $('.tablesorter').dataTable({
"aaSorting": [[2, "asc"]],
"bAutoWidth": false,
"bFilter": false,
"sDom": 'T<"clear">lfrtip',
"aoColumns": [
{ "sType": "html" },
{ "sType": "html" },
null
],
"oLanguage": {
"sUrl": "templates/rhuk_milkyway/dataTables/media/language/it_IT.txt"
}
});
При этом у вас есть нумерация страниц и фильтрация на стороне сервера.
РЕДАКТИРОВАТЬ 3 - в случае, когда вы упомянули (таблицы данных заботятся о разбивке на страницы, но не требуют фильтрации), я думаю, вы должны добавить дополнительный плагин. Вы должны отключить фильтры и сортировщики данных на этапе инициализации, как это;
"bFilter": false,
"bSort": false,
А затем используйте другой компонент для сортировки, фильтрации того, что на экране. Решение с сортировкой и фильтрацией можно посмотреть здесь: http://silverwareconsulting.com/index.cfm/2008/10/2/jquery-autofiltering-table
(лично мне не нравится идея фильтрации по щелчку, но вы можете использовать это, если хотите использовать что-то большее на свой вкус), в любом случае вы не можете использовать встроенные фильтры datatables, если вы разрешаете серверную часть нумерация страниц
У меня работает что-то почти идентичное, и решение полностью конвейерно — ничего волшебного и нет необходимости объединять другие решения. Установите высокий объем конвейера — в моем случае я получаю по существу 5 «групп» результатов (страницы * результаты отображения) как вперед, так и назад — и верьте, что Datatables сделает все остальное.
В одном экземпляре моего приложения я имею дело с более чем 5 миллионами записей. Да, это много. Я провел массу тестов на различных элементах системы, включая запросы, оптимизацию базы данных, индексирование и использование шаблонов пользовательского интерфейса. Все указывает на то, что эта система является наиболее эффективной в данной ситуации. В вашем случае я настоятельно рекомендую проводить мониторинг производительности независимо от вашего решения пользовательского интерфейса, чтобы увидеть, какие (если таковые имеются) узкие места существуют. В моей системе с более чем 5 миллионами записей я рассчитываю примерно на 2-4 секунды времени запроса и +-5% нагрузки на страницу или сортировку, что, безусловно, управляемо. У меня есть сотни пользователей и довольно много других процессов, с которыми нужно иметь дело одновременно, и мы не наблюдаем заметного отставания с момента внедрения нескольких таблиц данных около 6 месяцев назад.
С точки зрения пользовательского интерфейса слабость сортировки только данных на экране заключается в том, что она не интуитивно понятна. Когда у меня есть доступ к тысячам или миллионам записей в сетке, и я сортирую или фильтрую их, я ожидаю увидеть сортировку и фильтрацию всех доступных записей. Звучит глупо, но помните, что вся наука о дизайне пользовательского интерфейса заключается в создании шаблонов, «знакомых» пользователю.
