Отображение множества записей в веб-приложении без использования громоздкой системы подкачки

Question

У меня есть веб-приложение, которое извлекает и отображает записи из базы данных. Пользовательский запрос может соответствовать тысячам записей; в таких случаях для пользователя имеет смысл уточнить свой поиск.

В случае, если запрос соответствует сотням записей, пользователю, вероятно, имеет смысл просмотреть записи. Меня беспокоит то, что веб-приложение отображает «страницы» записей. В контексте веб-приложения я считаю, что пейджинг - это ужасный, ужасный способ отображения данных такого типа.

Представьте себе следующий сценарий:

1. Пользователь запускает запрос: приложение указывает, что имеется 20 страниц, и отображает страницу 1.

2. Пользователь нажимает на страницу 2, затем на страницу 3.

3. Пользователь понимает, что искомая запись находится на странице 2. Пользователь снова нажимает на страницу 2.

4. Пользователь считает, что он видел похожую запись на странице 1. Пользователь несколько раз нажимает взад и вперед между страницами 1 и 2, чтобы сравнить записи.

В веб-приложении при каждом изменении страницы требуется загрузка совершенно новой страницы. Конечный пользователь, вероятно, думает, что это просто загрузка большего количества данных, но для браузера это такая же работа, как и загрузка совершенно другой страницы. Кроме того, когда пользователь переключается между страницей 1 и 2, одни и те же данные загружаются с сервера снова и снова.

Это безумие, что с современным компьютером, оснащенным миллиардами байт памяти, мы привыкли думать, что для компьютера нормально загружать (через медленное соединение с высокой задержкой) текстовые данные, которые занимают мегабайты при самый самый.

У меня есть идея использовать JavaScript для автоматической загрузки новых записей каждый раз, когда пользователь прокручивает страницу до конца на странице записей (для пользователя не будет ссылок на пейджинг - записи будут просто загружаться как пользователь свитки). Это звучит хорошо; но один недостаток, который приходит на ум, состоит в том, что было бы трудно напечатать страницу без предварительного перехода в «дружественный к принтеру» вид.

Какие есть еще идеи по вставке приложения базы данных в веб-документ без использования громоздкой системы подкачки?

Answer 1

Ну, с самого начала я собирался предложить добавить новые записи по мере прокрутки страницы. Если вы беспокоитесь о получении действительно длинных страниц. Решение состоит в том, чтобы скрыть верхние записи, чтобы отображалось только максимальное количество записей. Тем не менее, вам нужно будет предоставить пользователю возможность выбора максимального значения или параметр отсутствия максимального значения таким образом, как все показывает. Кроме того, в зависимости от их выбора вам все еще может потребоваться версия для печати. Еще одно замечание: вероятно, было бы лучше добавить что-то на стороне, говорящее о позиции, как showing records 35-85 of 200.

Answer 2

Итак, в моем приложении у меня есть миллионы записей, которые пользователь может просматривать одновременно, по-видимому, все.

Я загружаю больше записей, запрашивая тот же URL, но меняя заголовки запроса.

Вот как вы можете что-то реализовать.

Предположим, вы хотите перечислить всех животных в мире в алфавитном порядке.Вы не хотите разбивать на страницы, располагая панель «» внизу.

1. Вы начнете и сразу же запросите свой "Ресурсный маршрут, который вернет набор животных: GET /resources/animals.

2. Ваш запрос будет включать заголовки, в которых указано, что именно вы запрашиваете.Например, добавьте заголовок range: 0-24.Смежный вопрос: добавление пользовательских заголовков HTTP с использованием Javascript

3. На стороне сервера вы можете выяснить, что пользователь запрашивает элементы от 0 до 24, и вы можете ответитьназад с заголовками ответа, сообщающими ему, что вы возвращаете, вот так: returned: 0-24/12000000.Это говорит клиенту, что вы вернули 25 предметов, начиная с пункта 0 и заканчивая пунктом 24, и осталось еще 12 миллионов элементов.

4. Визуализация элементов, полученных с сервера.

5. По мере того, как пользователь прокручивает страницу вниз, запрашивает следующий набор элементов.,Используя математику и выясняя, что в данный момент отображается, вы можете рассчитать, какую «страницу» просматривает пользователь, а затем запросить соответствующие результаты.

Вы можете увидеть, как это работает на практике здесь на примерах Dojo.

Подробнее об этом предмете.

Answer 3

Я бы пошел с «автоматически загружать новые записи, когда пользователь прокручивает вниз страницы».На мой взгляд, это один из самых удобных методов.

Для печати вы можете подстроить каждый разбитый на страницы набор, чтобы они получали класс «no_print» или что-то еще при загрузке нового набора.Динамически добавляйте / удаляйте этот класс, когда пользователь прокручивает назад.