Trimion pagination - получение общего количества результатов

Мы пишем некоторый код для управления разбиением на страницы результатов, полученных из запроса базы данных Tridion Broker (с использованием API).

Мы используем SDL Tridion 2011 SP1 и можем использовать PagingFilter для получения tcmIds только Компонентов на выбранной странице.

Однако при написании элемента управления pagination нам нужно знать общее количество результатов (чтобы определить, сколько страниц будет). Существует ли более эффективный механизм для этого, чем просто запуск отдельного запроса для результатов "все" и выполнение .Length для возвращаемого массива строк? (Очевидно, что вы только запускаете этот запрос один раз и сохраняете это значение, когда пользователь щелкает между страницами.)

Если мы получим все результаты, то зачем мне беспокоиться об использовании PagingFilter, когда мы можем просто обрабатывать информацию, возвращаемую в запросе "все"?

Большое спасибо заранее, Джонатан

ПРИМЕЧАНИЕ. Вероятно, будет получено не более 2000 результатов любого возвращаемого типа.

ОТВЕТЫ

Ответ 1

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

  • Невозможно использовать CD API для чтения COUNT возвращенных элементов. Вы можете написать, как бы продление. Будь то расширение хранилища CD или прямой запрос БД и т.д.

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

    /li >

  • Вы не заботитесь об общем количестве элементов в разбивке на страницы. Например, вместо того, чтобы отображать "Страница 1 из 23", "Страница 2 из 23" и т.д., Вы просто показываете Page 1, Page 2 со своими соседними и предыдущими кнопками рядом с ним.

Надеюсь, это поможет!

Ответ 2

Во время публикации вашего компонента вы можете реализовать TBB, который подсчитывает все ваши опубликованные компоненты, а затем публикует результат в текстовом или XML файле в виде двоичного файла, который вы читаете, используя стандартные функции system.io. Вы также можете опубликовать отдельный DCP специально для хранения счета (тогда вам понадобится схема и компонент для каждой публикации).

Идея состоит в том, чтобы определить Count во время рендеринга и как-то опубликовать этот номер. Вытягивание одного номера на стороне презентации было бы, конечно, быстрее, чем вытягивание 2000 DCP.