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

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

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

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

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

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

Примечание: Там, вероятно, будет не более 2000 результатов какого-либо одного типа, возвращенного.

источник

2012-03-23 Jonathan Williams

Я понимаю, что прежние объекты доставки, возвращаемые контентом, были кэшированы, но теперь (точное совпадение) запросы брокера кэшируются (поскольку Tridion 2011?) --_ возможно, это может быть причиной использования конкретного фильтра? Я видел разбивку на страницы с использованием JavaScript, но не уверен в идеях лучше, чем ваш подход к поиску. –

Большой вопрос Джон, не похоже, что вы можете выполнить запрос стиля «COUNT (....)». – Neil

Спасибо Нейлу. Да, мы думали, что может быть более эффективный механизм COUNT (...). Подход PagingFilter очень полезен, если вы ЗНАЛИ, сколько страниц у вас будет или вам не нужно знать, сколько страниц (и эффективно обрабатывать пустые массивы), но я бы подумал, что это довольно редко. –

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

Невозможно использовать CD API для чтения COUNT возвращенных элементов. Вы можете написать, как бы продление. Будь то расширение хранилища CD или прямой запрос БД и т. Д.
Вы читаете точное количество предметов, которые у вас есть в вашей коллекции. Это особенно сложно, если вы используете запрос для Компонентов с намерением получить DCP для этих Компонентов. Возможно, для данного компонента нет DCP, поэтому сначала вам нужно прочитать все DCP, чтобы узнать точное количество элементов, для которых вы хотите разбивать страницы. Очевидно, что это победит всю цель разбивки на страницы. Вы можете уменьшить это падение производительности, выполнив запрос один раз, а затем кешировать его некоторое время, но в зависимости от того, на что вы запрашиваете, может быть, что каждый посетитель сайта запрашивает разные термины, таким образом, высокая производительность.
Вы не заботитесь об общем количестве элементов в разбивке на страницы. Например, вместо того, чтобы отображать «Страница 1 из 23», «Страница 2 из 23» и т. Д., Вы просто показываете Page 1, Page 2 со своими соседними и предыдущими кнопками рядом с ним.

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

источник

2012-03-23 16:17:04

Спасибо, Михай. Я не рассматривал влияние отсутствия DCP для компонента (как вы подчеркиваете в своем втором предложении). Мне нравится идея расширения накопителя CD (так как нам, возможно, придется разрешить пользователям веб-сайта позднее фильтровать). Однако на данный момент я думаю, что мы, вероятно, воспользуемся предложением 2 и будем использовать кеширование. Большое спасибо! –

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

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

источник

2012-03-24 05:46:16

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

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

ответ

Смежные вопросы