Это просто пример "типа такого нужно", а сколько будет реально неизвестно.
Не важно какой запрос, вы же предлагаете все скопом на клиента скинуть.

конечно сервер не гарантирует получение данных в том порядке в которых вы их ввели в БД, но тогда в чем проблема завести счетчик по id и сортировать по id ?

Нее, база там будет не особо большая. И первая моя идея - была как раз - отдавать всю таблицу, а потом уже js, чтобы отбирал необходимое.
Выдать пользователю всю базу - тоже нет проблем, пущай смотрят.

Мне просто хотелось бы уменьшить писанину этого. С ajax - мне не разобраться быстро. Идеально было бы, если бы сервак отдавал статические данные, а на стороне клиента - уже все делалось.

Вопрос: как мне тогда перезаполнить таблицу по событию? Как само событие перехватить я знаю. А вот как перестроить таблицу. Мне ее надо перестраивать ? Но откуда тогда брать источник? Или перестраивать прямо то, что уже есть на странице?


P.S. Прошу простить, я в js - как-то совсем дуб дубом. Сам инженер-электронщик: на бейские писал, на сях, на ассемблере, на дельфях... Но с js - как-то много вопросов, ибо язык имеет другую идеологию.


P.P.S. Во какая идея рождается: первоначально дается полная таблица, а после нажатия - прямо на лету осуществляется сортировка таблицы и в зависимости от параметров - меняются строки местами (реализация сортировки).
Такое проканает ?

https://jsfiddle.net/1rev1rmv/1/

Вот небольшой пример, есть колонка с чекбоксами , есть колонка с таблицей... Самовызывающаяся функция перебирает все чекбоксы получает от каждого его data-item , далее перебирает всю шапку таблицы и получает от каждого name, если нашел совпадение проверяет чекнут ли чекбокс, false -> колонку в шапке скрывает и перебирает все tr где находит td соответствующего номеру колонки в шапке и скрывает его тоже...
Такой же принцип и у функции которая вызывается по клику на чекбоксы

Я уверен что laimas,
в силах упростить этот скрипт...))))):help:

Предлагаю сесть и подумать, что значит "сервак отдавал статические данные". Это, если понятие буквальное, статичный html-файл, один, в котором все, от разметки всей страницы, до данных "типа база". Другими словами базы как таковой нет.

Не надо заниматься ерундой когда есть готовое, нужно только научиться использовать это. Да, можно организовать базу данных на клиенте, и не надо ничего мудрить с localStorage, есть готовые решения. Но, они не обладают теми возможностями, которые изначально заложены в СУБД, а значит это нужно будет писать самому, и как вы это будете делать не зная даже простейшего из JS? Или вы думает, что написать такое проще чем написать ajax-запрос? Это заблуждение.

Открывайте отладчик браузера и контролируйте сеть, просматривая пример по вашей ссылке. Это и есть ответ на ваш вопрос как сделать - клиент отправляет запрос серверу как набор параметров фильтра, SQL нужно лишь сделать единственный запрос согласно этим параметрам. Результаты запроса возвращаются как json. Из этих данных клиент строит таблицу.

laimas,
Я думаю что Atridies сделает всю таблицу в html (не будет он её из БД загружать) а на js уже реализует фильтры...)) ибо молод он для php и ajax)

За "молод", спасибо :).

Тут вопрос в том, что для каждой задачи - есть свое оптимальное решение. Наверное с ajax - это более правильно. Но мне не хочется тратить время на его изучение (ибо мне это мало где пригодится в жизни), а кроме того, это потребует поднятия на сервере БД, установки серверного js, разбирательства в том, как это поставить на хостинге.

На первом этапе - для меня наиболее оптимально: сделать статическую страницу и перебирать ее на стороне клиента.

По мере роста проекта - переделаю это. Точнее - закажу специалисту и он - сделает как надо.


Еще спасибо за пример. Я там пока мало что понял, но это дело времени. Вещица полезная.


И, кстати, я проверял: сайт компэла - действительно не дает запрос на сервер при пересортировке. Так что похоже он также сделан...

а как вы это поняли?

Ну да, а судя по теме он специалист в JS, и написать выборку по фильтрам и сортировку по условиям ему как два пальца ..., в чем вы его упорно поддерживаете? :)

Мне все равно как он сделает, но если речь идет о некой базе, то это и должна быть СУБД, не надо ее подменять расплывчатыми понятиями ради сомнительных идей. СУБД, это не просто хранение данных, это их сопровождение, что подразумевает большой спектр понятий. Именно данные конкретной СУБД и будут определять дальнейший скелет веб приложения. Но даже не зная, что скрывается за страшной аббревиатурой СУБД, ему никто не мешает задать вопрос относительно ее - как сделать выборку данных по условиям, ответ будет короткий:

SELECT require_fields, filter_keys FROM table WHERE filter_keys=>filter_values ORDER BY filter_sort

СУБД под приложение проектируют так, чтобы данные в ней были оптимизированы, в частности, если по примеру, то производителей лучше хранить в отдельной связанной таблице, как и некоторые характеристики, которые могут распределять изделия описанные в СУБД по неким классам. Тогда запрос дополнится всего лишь вложенным запросом/запросами для объединения таблиц:

SELECT require_fields, filter_keys FROM table_name
LEFT JOIN table_property
join_conditions
WHERE filter_keys=>filter_values ORDER BY filter_sort

где join_conditions условия по равенству полей, по которым происходит объединение данных в запросе. Все остальное это:

require_fields - поля SQL таблицы, которые должны быть всегда отображаться на клиенте не зависимо от параметров фильтра, если такое необходимо,

filter_keys - ключи массива filter параметров фильтра полученного от клиента и определяющие запрашиваемые поля SQL таблицы,

filter_keys=>filter_values - ключи->значения массива filter параметров фильтра определяющие условия выборки, если это необходимо и выбрано,

filter_sort - поля определяющие сортировку результата выборки данных.

Если при этом работать в PDO, то предварительная обработка полей массива filter перед передачей их в запрос не требуется - в качестве полей условий выборки подставляются именованные параметры :filter_key или неименованные (знак вопроса ?), а в качестве данных соответственно ассоциативный массив фильтра (как есть), или только его значения.

Отдать клиенту полученное при этом совсем просто - echo json_encode($pdo->fetchAll()). В случае работы непосредственно с MySQL, что настоятельно не рекомендуется разработчиком, будет добавлена предварительная обработка входных данных (параметров фильтра), а получение массива данных из записей, это цикл while.

И здесь больше моих слов, чем будет символов в реальном коде выборки данных из базы, который даже на средненьком форуме ему покажут. Мои слова ради объяснения того, что все просто. Если есть необходимость работать с базой на клиенте, то и в этом случае нужно работать с базой, а не localStorage в чистом виде, и для этого тоже уже есть готовое, не надо изобретать лисапеда. И только, если данные, это бублики с дырочками или без них, с маком или без него, и бублики будут вечны, можно рассуждать о плюшках, которые легко вписываются в нечто легкое для localStorage. Вот только по ссылке "типа этого" данные ну никак не вписываются в простоту, о которой вы утверждаете, значит вы не понимаете ни как подобные данные организуются, как связываются и как обслуживаются. А автору темы описывать свои конкретные данные, которые как он пишет будут просты до смешного, и забудет о понятие базы, и прописывает их сразу в js-файл объектом, или грузит единожды в localStorage, поступая по личному вкусу. Иначе получается, что ссылаются на серьезные темы, а разговор хрен знает о чем.